Ruby on Rails中的消息队列

时间:2009-04-06 12:52:49

标签: ruby-on-rails ruby message-queue background-process

人们使用Rails应用程序的消息队列是什么,以及决定选择它的驱动力是什么。最新的Twitter宣传其内部队列Starling垮台是否会影响任何现有的设计决策。

我正在开发一个需要消息队列来处理一些后台任务的应用程序,我没有做太多这样的事情,我过去看过的大部分内容都是关于Starling和Workling,以及说实话,应用程序不是很大,这个解决方案可能已经足够了,但我很乐意获得集成最佳解决方案的经验,因为我确信我会在某个时候将其集成到更大的应用程序中。

你会为Rails应用程序建议什么消息队列?

编辑:感谢您提出的建议,本周末我将会看一些建议。

再次编辑:我已经环顾四周,有点不知所措。然而,我将把RabbitMQ和Workling集成到我正在构建的应用程序中,然后如果我需要一些关于快速队列的知识,那么我将拥有它并知道它是否符合我的需求。

编辑:发现越来越多的DJ适合我,如果我在网站上“长大”,我会说Resque是我要去的地方。

编辑:( 2014年12月)所以我问这个问题已经有很长一段时间了,但是我觉得它仍然会得到一些观点或一些投票,所以当我谈到我的选择时,我想我会更新它的方法背景工作者。

在我看来,目前在Ruby中运行后台作业的最佳方法是使用Sidekiq。很多人真的称赞Sidekiq是因为它是线程化的工作者,而不是每个工人的处理能够使用比Reski更少的内存,而Resque就是我在Sidekiq之前使用的。这很好,但对我来说,这不是杀手级的功能。通过将Sidetiq与Sidekiq一起使用,作业的调度是如此微不足道,以至于我切换了它并且从未回头过它,到目前为止我使用过的最简单的作业调度并使Sidekiq变得轻而易举。

7 个答案:

答案 0 :(得分:16)

作为更新 - GitHub已经迁移到Redis上的Resque而不是Delayed job。但是,对于较小的设置,他们仍然建议使用delayed_job:

https://github.com/resque/resque

答案 1 :(得分:9)

来自github的Chris Wanstrath最近参加了SF Ruby聚会,讨论了他们的队列。在确定Shopify的delayed_job之前,他们尝试过Starling,beanstalk和其他一些变体。他们使用背景非常积极。

这是一个blog post from last year,谈到他们转向DJ。

我现在在几年前推出了自己的产品,但我正在从DJ那里获取一些改进处理的想法。

答案 2 :(得分:9)

如果您不期望任何重负载,我会建议delayed-job作为一个简单的解决方案。优点:易于设置,易于监控,代码简单,没有任何外部依赖性。以前我们使用ActiveMessaging(使用ActiveMQ和stomp),但这对我们的项目来说太过分了,所以我们为了简单起见切换到delayed_job。

无论如何,如果你需要非常成熟和快速的解决方案,ActiveMQ是一个非常好的选择。如果你不想花太多时间来维护你真正不需要的全面消息排队解决方案,那么delayed_job是一种可行的方法。这是关于使用ActiveMQ的Scribd体验的good article

答案 3 :(得分:4)

以下是一些Ruby / Rails解决方案,根据您的需要,其中一个或多个可能非常合适:

http://xph.us/software/beanstalkd

http://rubyforge.org/forum/forum.php?forum_id=19781

http://backgroundrb.rubyforge.org

而且,来自亚马逊的托管解决方案将为Ruby / Rails与更大系统的其他组件之间的共享创建一个很好的队列:

http://aws.amazon.com/sqs

希望这有帮助!

答案 4 :(得分:3)

您可能想要使用的Messaging Server是RabbitMQ。 Erlang coolness,AMQP,优秀的Ruby库。

http://www.bestechvideos.com/2008/12/09/rabbitmq-an-open-source-messaging-broker-that-just-works

答案 5 :(得分:2)

Rany Keddo去年在RailsConf欧洲发表了关于Starling + Workling的useful presentation。他比较了当时可用的不同解决方案。

Twitter最近离开Starling + Workling可能对常规rails应用程序没什么意义。他们有更多的规模问题,并且他们的数据存储可能存在遗留问题,导致他们无法扩展到当前的实现。

Beanstalkd是一个很好的选择,只是因为它作为守护进程运行并且在其他脚本语言中有包装(如果你将来改变方向或者用其他语言编写不同的组件)。

这个link也可以很好地比较各种铁路解决方案的优缺点。

答案 6 :(得分:1)

我使用background_jobdelayed_job是基于数据库的队列。

只要您没有进行过多的流量管理,数据库就会建立一个OK队列。

我喜欢background_job(和delayed_job)的原因是它们不需要单独的进程。他们可以通过cron。对我来说,这是至关重要的,因为我的消息传递需求甚至比我微薄的系统管理员技能更简单。