关于 Ruby / Rails 的线程模型

inu 的项目中有一个导入功能,将用户从浏览器、del.icio.us 导出的收藏条目导入到 inu 收藏夹中。这个功能推出以来,用户的反响并不好,其主要原因在于:速度慢,考验用户的耐心。

速度慢的问题,根本原因在于 model 层需要做的工作非常多,也是目前不完善的架构以及比较特殊的需求导致的,可以说不能从根本上解决。每次导入一条记录,都需要更新好几个表,本身 Ruby 在目前虚拟机下效率并不高,所以导入的速度并不理想。

那么,退而求其次,可以设置一个直观的进度条来告诉用户目前导入的进度,可以在很大程度上缓解用户的焦虑、不信任的心理。

解决方案是确定了,可是问题由此而来:Ruby 是单线程的。

严格来说,应该是目前的虚拟机还不支持真正多线程的 Ruby 应用。虽然 Ruby 中确实有 Thread 类 ,但是查阅相关文档可以知道,这个类是一个伪 Thread,不同于真正的多线程。如果通过 join 将子线程挂到当前的主线程中(某个 mongrel 进程),那么该线程在结束之前会等待所有的子线程结束。通常情况下这种机制可以模拟出和其他语言相类似的线程模型。但是在 Rails 中,有新的问题产生:无论是 FastCGI 还是 Mongrel ,都是一个请求独占一个进程,每次请求都会创建新的 Controller 实例,请求结束后该实例销毁。也就是说,在 Controller 内无论是不使用线程、或是把子线程挂到主线程上,在所有操作结束之前,当前进程一直处于 block 状态。

很可怕!

通常用 Thread 是在不影响主线程的情况下处理耗时很多的操作。但是这种机制明显不能应付这种需求。一台服务器上 mongrel 数量有限,都被阻塞了,相当于服务器在这段时间内不能接收其他的请求。

那么是否让 Thread 单独执行就可以了呢?答案也是否定的。在单独的线程中,Model 类将不再是 Model。其实意思是:线程中的 ActiveRecord 类不再具有标表间关联(目前我测试出来就这么多,可能还会失去更多东西),只是一个普通的实体类。对于这样的导入,无疑就是毁灭性的。

至此,可以确定,这个应用不可避免的要阻塞一个 mongrel 了。那么如果要反应当前导入的进度,就是要发起一个新的请求,查询导入状态。如果这个请求发送到 Rails ,意味着用户的导入要占用 2 个 mongrel ,服务器不可能有这么多的资源。

最终我采取了一种折中的方案,导入时创建一个可访问的静态资源,查询进度的功能由这个静态资源来完成,而 Web 应用对于静态资源的访问则由 Apache 来完成。

至此,问题算是解决了,虽然算不上完美。期望 Ruby 的虚拟机能够尽快支持 Multi-Thread 吧!

Comments

comments powered by Disqus