Ruby on Rails 中的消息队列

Message Queues in Ruby on Rails

提问by nitecoder

What message queues are people using for their Rails apps and what was the driving force behind the decision to choose it. Does the latest Twitter publicity over their in house queue Starling falling down affect any existing design decisions.

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

I am working on an app that will need a message queue to process some background tasks, I haven't done much of this, and most of the stuff I have seen in the past has been about Starling and Workling, and to be honest the application is not very big and this solution would probably suffice, but I'd love to get experience integrating the best solution possible as I'm sure I will integrate one into a bigger app at some point.

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

What message queues would you suggest for a Rails app???

你会为 Rails 应用推荐什么消息队列？？？

EDIT: Thanks for the suggestions, I'm going to look at a few of them this weekend.

编辑：感谢您的建议，我将在本周末查看其中的一些。

EDIT Again: I've had a look around and a little overwhelmed for choice. I am however going to go about integrating RabbitMQ with Workling into the app I am building, then if I ever need some knowledge about a fast queue then I will have this and know whether or not it fits my needs.

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

EDIT: Finding more and more that DJ suits me just fine, if I ever "outgrow" it on a site I'd say that Resque is where I would head.

编辑：找到越来越多的 DJ 适合我就好了，如果我在网站上“长大”，我会说 Resque 是我要去的地方。

EDIT: (Dec 2014) So it's been a long time since I asked this, but I see it still gets some views or some votes, so I figured I'd update it on my approach now when it comes to my choice of background workers.

编辑：（2014 年 12 月）所以我问这个问题已经很长时间了，但我看到它仍然得到一些观点或一些投票，所以我想我现在在选择后台工作人员时会更新我的方法.

In my opinion currently the best way to run background jobs in Ruby is using Sidekiq. A lot of people have really lauded Sidekiq for it's threaded workers rather than process per worker which can use significantly less memory than the likes of Resque, which I was using before Sidekiq. This is good but for me this wasn't the killer feature. By using Sidetiq with Sidekiq, the scheduling of jobs is so trivial that I switched over and have never looked back from it, by far the easiest scheduling of jobs that I have used and has made Sidekiq a breeze to use.

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

采纳答案by Julian H

As an update -- GitHub have moved to Resque on Redis instead of Delayed job. However they still recommend delayed_job for smaller setups:

作为更新 - GitHub 已迁移到 Resque on Redis 而不是 Delayed 作业。但是，他们仍然建议将 delay_job 用于较小的设置：

https://github.com/resque/resque

https://github.com/resque/resque

回答by Oleg Shaldybin

I would recommend delayed-jobas a dead simple solution if you don't expect any heavy load. Pros: easy to setup, easy to monitor, simple code, doesn't have any external dependencies. Previously we used ActiveMessaging (with ActiveMQ and stomp), but it was an overkill for our project, so we switched to delayed_job for its simplicity.

如果您不希望有任何重负载，我会推荐延迟作业作为一种简单的解决方案。优点：易于设置，易于监控，代码简单，没有任何外部依赖。之前我们使用了 ActiveMessaging（使用 ActiveMQ 和 stomp），但是这对我们的项目来说太过分了，所以为了简单起见，我们改用了 delay_job。

Anyway, if you need very mature and fast solution, ActiveMQis a very good choice. If you don't want to spend too much time on maintaining full-scale message queueing solution you don't really need, delayed_job is a way to go. Here's a good articleabout Scribd experience with ActiveMQ.

不管怎样，如果你需要非常成熟和快速的解决方案，ActiveMQ是一个非常好的选择。如果您不想花太多时间维护您并不真正需要的全面消息队列解决方案，则delayed_job 是一个不错的选择。这是一篇关于使用 ActiveMQ 的 Scribd 体验的好文章。

回答by Sarah Mei

Chris Wanstrath from github was at the SF Ruby meetup recently, talking about their queue. They tried Starling, beanstalk, and some other variants before settling on Shopify's delayed_job. They are pretty aggressive with their use of backgrounding.

来自 github 的 Chris Wanstrath 最近在 SF Ruby 聚会上，谈论他们的队列。在确定 Shopify 的 delay_job 之前，他们尝试了 Starling、beanstalk 和其他一些变体。他们对背景的使用非常积极。

Here's a blog post from last yearthat talks about their move to DJ.

这是去年的一篇博客文章，谈论他们转向 DJ。

Where I am now we rolled our own several years ago, but I'm taking some ideas from DJ to improve the handling.

我现在所处的位置我们几年前推出了自己的产品，但我从 DJ 那里汲取了一些想法来改进处理。

回答by Adam Alexander

Here are a few Ruby/Rails solutions, one or more of these may be a good fit depending on your needs:

以下是一些 Ruby/Rails 解决方案，其中一个或多个可能适合您，具体取决于您的需求：

http://xph.us/software/beanstalkd

http://xph.us/software/beanstalkd

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

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

http://backgroundrb.rubyforge.org

http://backgroundrb.rubyforge.org

And, a hosted solution from Amazon which would make a great queue for sharing between Ruby/Rails and other components of a larger system:

并且，来自 Amazon 的托管解决方案将为 Ruby/Rails 和更大系统的其他组件之间的共享提供一个很好的队列：

http://aws.amazon.com/sqs

http://aws.amazon.com/sqs

Hope this helps!

希望这可以帮助！

回答by Sebastian

The Messaging Server you might want to go for is RabbitMQ. Erlang coolness, AMQP, good Ruby libs.

您可能想要使用的消息服务器是 RabbitMQ。Erlang 很酷，AMQP，优秀的 Ruby 库。

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

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

回答by Pras

Rany Keddo gave a useful presentationabout Starling + Workling at RailsConf Europe last year. He compared the different solutions available at the time.

Rany Keddo 去年在 RailsConf Europe 上做了一个关于 Starling + Workling的有用演讲。他比较了当时可用的不同解决方案。

Twitter's latest move away from Starling + Workling probably doesn't mean much to the regular rails app. They have a lot more issues of scale and probably have legacy issues with their datastore that prevents them from scaling past their current implementation.

Twitter 对 Starling + Workling 的最新举措可能对常规 Rails 应用程序意义不大。他们有更多的规模问题，并且他们的数据存储可能存在遗留问题，从而阻止他们扩展超过当前实施。

Beanstalkdis a good alternative, simply because it runs as a daemon and has wrappers in other scripting languages (if you happen to change direction in the future or have different components written in other languages).

Beanstalkd是一个不错的选择，因为它作为守护程序运行，并且具有其他脚本语言的包装器（如果您将来碰巧改变方向或使用其他语言编写不同的组件）。

This linkalso has a good comparison of pros-cons of the various rails solutions available.

此链接还对可用的各种导轨解决方案的优缺点进行了很好的比较。

回答by Luke Francl

I use background_jobwhich like delayed_jobis a database-based queue.

我使用background_job，其中delay_job是一个基于数据库的队列。

A database makes an OK queue as long as you're not doing too much traffic in and out.

只要您没有进行过多的进出流量，数据库就会构成一个 OK 队列。

The reason I like background_job (and delayed_job) is that they do not require a separate process. They can run through cron. For me, this is of key importance because my messaging needs are even simpler than my meager sysadmin skills.

我喜欢background_job（和delayed_job）的原因是它们不需要单独的进程。它们可以通过 cron 运行。对我来说，这非常重要，因为我的消息传递需求甚至比我微薄的系统管理员技能还要简单。