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:
