rails3项目解析之4——异步和定时任务

在当前的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： 

rake --trace resque:work QUEUE=* VERBOSE=1 RAILS_ENV=production

2.2 调用enqueue方法来产生异步任务。 

Resque.enqueue(Sendmail, email)

第一个参数是执行该任务的类，在这个类中，需定义一个类方法perform 

class Sendmail
  def self.perform(email)
    。。。。。。
  end
end

除了第一个定义类的参数，enqueue方法中其它的所有参数，都将被作为参数传入perform方法。 

这里需要注意的一点就是，resque在根据enqueue方法构造消息存入redis的时候，保存的是json的格式，也就是说，enqueue传入的参数，必须是属于简单类型，可被转化为json的，例如string、integer等，不能传入一个复杂类或自定义类的实例。如果必须要在任务中使用对象，则可以传入id，执行任务时再从数据库中取对象，或者是把实例用marshal序列化传入。等等。但序列化的方式一般不推荐使用。 

3、定时任务 

resque的异步任务只能是立即执行的，如果要求这个任务延时比如1个小时后再执行，或者是要求某些任务在某个时刻定时执行，则需要使用resque的定时任务插件resque-scheduler。 

3.1 resque-scheduler的原理是，底层使用rufus-scheduler启动一个定时器，定时器从配置文件中获取所有的任务列表，根据列表中的指定时刻，产生resque任务，插入redis消息队列，然后该任务被resque的worker执行。 

rufus-scheduler可以使用plain方式，也可以使用eventmachine方式。plain方式就是启动一个loop轮循，比较简单粗糙，因此为了保证健壮性，建议使用eventmachine。无需特别配置，只需在项目中加入eventmachine的gem，rufus即可自动识别并使用EmScheduler模块。 

需启动一个rake命令，来调入scheduler配置文件并定时产生各项任务： 

rake --trace resque:scheduler RAILS_ENV=production

3.2 定时任务写在scheduler.yml文件中，由resque-scheduler的rake命令调用。典型的任务格式为： 

redis_bgrewrite_aof:
  cron: "0,20,40 * * * *"
  class: RedisRewriteAof
  args: 'localhost:6379'
  queue: application
  description: "每20分钟重写redis的binlog"

cron就是crontab所使用的格式，免除额外的学习成本，即看即用。 
class就是resque的执行类，如上文所述，在该类中定义类方法perform来执行任务。 
args是传入perform方法的参数，同样，必须是可以json encoded的简单类型。 
queue是队列名称，不指定的话就使用默认队列。 

其中，cron也可以更换为every指令，every: 3m，就是每3分钟。 

4、异常退出和解决 

在实际使用中，发现rake resque:work和rake resque:scheduler两个命令驻留进程后，都会因为某些任务执行时一些莫名其妙的异常而全部退出。trace日志也明确地指出了这一点。因此需要在这两个rake命令之上，加入监控脚本，在rake退出之后重新启动之。 

4.1 使用rufus-scheduler启动一个监控，每秒调用系统命令执行一次扫描： 

ps -eo pid,command | grep resque | grep -v grep

计算正在运行中的worker的数量，如果低于某个指定值，即说明有某个worker已异常退出，则启动rake命令再次加入rake resque:work直至达到指定值。 

4.2 使用rufus-scheduler启动一个监控，每秒调用系统命令执行一次扫描： 

ps -eo pid,command | grep resque:scheduler | grep -v grep

如果没有找到含有resque:scheduler的进程，则调用rake命令重新启动之。 

5、高可用 

5.1 resque:work的高可用比较好解决，同时启动两台甚至多台服务器，在每台服务器上都运行监控脚本启动数个worker，根据系统的负载做出一定的冗余，这样即使有一台服务器宕机也不会影响到任务的执行。 

5.2 resque:scheduler稍微麻烦一点。因为不能启动两台服务器同时跑定时任务，否则每个任务都会被执行两次，造成资源的浪费和潜在的问题，何况这样也不优雅，简单粗暴得让人鄙视。最终我们采用了与keepalived相结合的解决方案。在resque:scheduler监控脚本中，加入一个判断命令： 

ip a | grep 10.0.0.100

其中10.0.0.100是keepalived的VIP（虚拟IP），判断如果该VIP正在本机，则监控脚本启动rake resque:scheduler。如果运行scheduler的服务器宕机，则10.0.0.100的VIP会马上跳到另一台备用服务器上，该服务器上的监控脚本会扫描到该VIP的存在，从而在本地启动rake resque:scheduler命令，继续产生定时任务。 

6、管理界面 

resque自带一个简单的管理界面，你可以在这个界面上查看队列中的任务，当前正在执行的任务，已执行完毕的任务，执行成功和错误的详情。并且可以手动清空队列。等等。虽然都是些常用功能，但一图顶千言，看起来直观方便，也聊胜于无而已。 

 

 

7、仍存在的问题 

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

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

 

Q1

rufus-scheduler是基础组件，resque-scheduler本身就是使用rufus来作为底层核心的。但resque-scheduler为我们做了很多的事情，不必再从rufus的基础上一点点做起。比如你可以把任务都统一写在一个配置文件里，而不是散落在各处的代码里，有利于修改和维护。

 

Q2

举的这个例子正好说明不应该在项目中直接用rufus，而应该用resque。 

象rufus这种基于定时机制的组件，不应该由rails应用的initializer来启动，会有很多的隐患。rails的启动机制就很复杂，再加上生产环境的passenger，更难于控制。而且象例子中那样，在rufus中执行任务每次都要调一个新的rake，速度慢，多了很多不必要的浪费。我上面也说了，rufus只是一个底层机制，resque-scheduler只是在rufus外面包装了一下，再跟resque做个配合。有这样搭积木的好事为什么不用。 

resque:worker和resque-scheduler都是直接启rake的，rake启动了之后就驻留，scheduler生成任务和worker执行任务时，都不用再重新加载rails环境，所以执行速度非常快。并且它和passenger没有任何的关系，解耦比较好。比如在我们的生产环境中，就是有两台服务器专门来跑后台的，如果后台任务负载加重了，再多加几台专跑后台的服务器就行了。如果和passenger应用绑在一起，要是web服务器水平扩展到10台了，上面绑的后台任务肿么处理呢。 

crontab确实很稳定，这个大家都承认，但还要看用起来是不是舒服，发布代码的时候是不是方便。我们的项目都是用capistrano做发布，一个命令就可以完成所有的发布过程，如果和crontab绑定了，恐怕要多费很多力气。我们现在用resque和resque-scheduler，跑了半年，很稳定，让人感觉很踏实。 

至于你说的应用任务是不是复杂这个问题，就算再简单的定时任务，如果搞上几十个，恐怕写在代码里也不好管理吧。resque-scheduler是把任务写在yml中，看起来非常清晰。而且每个任务单独定义一个类，互不干涉，维护的时候也安全省事。

 

Q3

whenever本质上还是cron调用rake或runner，每次rake命令都要重新加载所有的rails环境，速度慢，还多了很多不必要的资源浪费。delayed_job是用数据库来存储任务的，不想再给数据库增加更多负担了。 

whenever只有定时任务没有异步任务。 

delayed_job只有异步任务没有定时任务。