rails3项目解析之4——异步和定时任务
上一篇：rails3项目解析之3——redis


在当前的web应用中，尤其是互动概念越来越大行其道的今天，为了加快网站的反应速度，提高用户体验，有些操作不能等到所有的后台处理完成之后再展现给用户，因此需要引入异步任务机制。典型的应用场景如用户注册完成之后的确认邮件发送，如果等邮件发送成功再给用户返回确认信息，这个时间间隔在用户体验上是难以接受的。另外，由于用户量和数据量的庞大，某些数据在平时只能做增量处理，需要在例如凌晨负载较小时对数据进行集中处理，这就需要引入定时任务。

1、技术选型

针对异步和定时任务的组件选择，我们当时颇费了一番功夫。可选的很多，而且网上也没有压倒性的信息可供参考和选择，因此只能对几种解决方案进行了概略地尝试和评测。

1.1 crontab+rake（runner）。据我所知，这种方式有些项目在使用，优势是比较简单，没有附加的学习成本，但这个方案很快就被我们否决，原因是和操作系统绑定最为紧密，权限上也要做一些相应的调整，不利于项目的自动发布，而且rake命令需要启动加载整个rails项目环境，速度和资源占用上有较大的劣势。

1.2 workling+starling。传说这是twitter当初自己做的东西，我安装试用了一下，评价仅仅是可用。后来经过几次测试，感觉配置和使用比较复杂，而且这套组件已经很长时间都没有更新了，看起来没什么活力，估计马上就要被宣布停止使用而碾碎掩埋了。遂弃用之。

1.3 另外象delayed_job、background_job、background_fu等等这些组件，不是功能不全不能满足需求，就是消息队列基于数据库，要么就是扩展性不好没有想象空间，因此都不合乎项目的要求。

1.4 最后，选定了resque和resque-scheduler套件作为异步/定时任务的组件。其优点在于功能比较强大，可扩展性好，已有数个各种不同目的的扩展可用。使用redis作为消息队列的存储，比较与时俱进，与操作系统无绑定，完全在rails框架内运行，配置和使用简单可理解。而且它是github贡献出来的开源组件，目前似乎仍然在github上跑着，稳定性无庸置疑。所以相信它一定能够满足我们项目的需求。至于你信不信，我反正是信了。

2、异步任务

2.1 异步任务主要由resque来实现。其原理是每当定义一个任务，就把这个任务写入redis的一个消息队列，resque的worker再轮循从队列中取消息，根据取出的消息构造任务，然后执行。

执行任务是resque的worker来完成的，需要启动一个rake命令来产生worker：

7、仍存在的问题

到目前为止，resque套件运行还算正常，该做的事都做了，不该做的事也不会做。但仍然还有一个问题迟迟未能解决。

worker执行任务，到公司oracle服务器和搜索引擎中获取数据时，有时会出现假死现象，就是说没有取得数据，但oracle数据库和搜索引擎的http接口却一直也不给超时中断的指令，任务就一直挂在那里，始终占用一个worker进程。而且我们也针对worker加入了使用SystemTimer的timeout强制中断措施。但这个timeout时间短的时候有效，时间一长比如几个小时，就无效了，到了超时时间也不会中断，真是奇哉怪也。尤其是timeout，按说SystemTimer是很可靠的，但至今我们都找不到准确的原因所在。这只能说是一个奇迹。如果你非要问我为什么，我只能说，它就是这样发生了。    1 楼    czarsir    2012-08-28              1.4节---至于你信不信，我反正是信了。 
结尾的---这只能说是一个奇迹。如果你非要问我为什么，我只能说，它就是这样发生了。 


感觉楼主不仅技术强悍，还很幽默。