Background Jobs in Rails

bj

队列主要是异步执行,提高应用的响应时间。
一般需要连接第三方服务器的API调用,邮件发送,统计计算等耗时不可知或平均超过1秒的工作,应该放入队列推迟执行。

系统中总有一些任务,是不需要用户及时得到数据,这时就应该考虑使用后台任务。理论上只要是能延迟的操作就应该放到后台去执行,比如发送短信验证码、移动设备通知、邮件通知等等。这样子,我们就能让每个请求在最短的时间内完成,提高整个系统的吞吐量。

有时,也有一些任务是需要第三方平台支持,返回时间无法得到保障,也可以考虑将其放到后台去执行。

delayed_job

delayed_job

https://github.com/collectiveidea/delayed_job
http://railscasts.com/episodes/171-delayed-job

Delayed Job使用当前数据库,会在当前库上建立新的表,使用该表作为Queue,这种作法很简单,也注定了其性能。一般小型站点可以选用。

但本人介意这种弄脏现有数据库的行为,更偏向于性能更好的,使用另处数据库的以下两种。

Resque

resque
http://railscasts.com/episodes/271-resque

Sidekiq

sidekiq

http://sidekiq.org/
https://github.com/mperham/sidekiq
http://railscasts.com/episodes/366-sidekiq

关于这三者之前的对比:
https://github.com/mperham/sidekiq/wiki/FAQ

API 不太一样。一开始我们用 resque 后来改 sidekiq。 resque 比较有历史,所以第三方插件齐全的多,问题是每一个 worker 都是自己的进程所以内存耗比较多。

sidekiq 的 workers 是 thread, 要小心 thread-safety 的问题。我们有一个第三方的 gem 不是 thread-safe。

Sidekiq 是一个简单强大的消息队列系统,目前可以说是 Ruby 世界里后台处理的首选。同类的选择还有 resque、delayed_job 等,但是 Sidekiq 之所以能迅速成为首选是基于两个特点,一是基于 Actor 模式的并行处理机制,二是基于 Redis 的 pubsub 模型,所以能用更少的内存资源来获得一样的处理能力。Sidekiq 在收到消息后会在后台处理,即使失败了也会重试,更加可靠。

REF::

http://joshrendek.com/2012/11/sidekiq-vs-resque/
http://www.octolabs.com/blogs/octoblog/2013/12/13/background_smackdown_resque_vs_sidekiq/
http://stackoverflow.com/questions/11580954/resque-vs-sidekiq