Очереди сообщений в Ruby on Rails

Question

Какие очереди сообщений используются для приложений Rails и что является движущей силой решения о выборе. Означает ли последняя реклама в Twitter по поводу их очереди в доме, когда Starling падает, влияет на любые существующие дизайнерские решения.

Я работаю над приложением, которое будет нуждаться в очереди сообщений для обработки некоторых фоновых задач. Я не сделал этого много, и большинство вещей, которые я видел в прошлом, касались Starling и Workling, и честно говоря, приложение не очень большое, и этого решения, вероятно, будет достаточно, но я бы хотел получить опыт интеграции наилучшего решения, так как я уверен, что в какой-то момент я буду интегрировать его в большее приложение.

Какие очереди сообщений вы предлагаете для Rails-приложения ???

EDIT: Спасибо за предложения, я собираюсь посмотреть на некоторые из них в эти выходные.

EDIT Снова: Я осмотрелся и немного перегружен для выбора. Однако я собираюсь объединить RabbitMQ с Workling в приложении, которое я создаю, тогда, если мне когда-нибудь понадобятся некоторые сведения о быстрой очереди, тогда я получу это и узнаю, соответствует ли он моим потребностям.

EDIT: Найти все больше и больше, что DJ подходит мне просто отлично, если я когда-либо «перерастую» его на сайт, я бы сказал, что Resque - это то место, где я бы направлялся.

EDIT: (декабрь 2014 г.) Так что я долгое время просил об этом, но я вижу, что он все еще получает некоторые взгляды или некоторые голоса, поэтому я решил, что обновляю его при моем подходе сейчас, когда дело доходит до моего выбор фоновых работников.

На мой взгляд, в настоящее время лучшим способом запуска фоновых заданий в Ruby является использование Sidekiq. Многие люди действительно похвалили Sidekiq за то, что это рабочие с резьбой, а не с процессом на одного работника, который может использовать значительно меньше памяти, чем подобные Resque, которые я использовал до Sidekiq. Это хорошо, но для меня это не была функция убийцы. Используя Sidetiq с Sidekiq, планирование заданий настолько тривиально, что я переключился и никогда не оглядывался назад, на сегодняшний день это самое простое планирование работы, которое я использовал, и сделало Sidekiq легким в использовании.

Answer 1

Как обновление - GitHub переместились в Resque на Redis вместо отложенной работы. Однако они по-прежнему рекомендуют delayed_job для небольших установок:

https://github.com/resque/resque

Answer 2

Вот несколько решений Руби/Rails, один или несколько из них могут быть хорошо подходят в зависимости от ваших потребностей:

http://xph.us/software/beanstalkd

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

http://backgroundrb.rubyforge.org

И размещенное решение от Amazon, которое сделало бы большую очередь для совместного использования между Ruby/Rails и другими компонентами более крупной системы:

http://aws.amazon.com/sqs

Надеюсь, это поможет!

Answer 3

Крис Ванстрат из github недавно был на собрании SF Ruby, рассказывая о своей очереди. Они попробовали Starling, beanstalk и некоторые другие варианты, прежде чем поселиться на задержанном_объекте Shopify. Они довольно агрессивны с использованием фона.

Вот blog post from last year, в котором говорится об их перемещении в DJ.

Где я сейчас, мы катались несколько лет назад, но я беру идеи от ди-джеев, чтобы улучшить обработку.

Answer 4

Rany Keddo дал useful presentation о Starling + Workling на RailsConf Europe в прошлом году. Он сравнивал различные решения, доступные в то время.

Последний шаг Twitter от Starling + Workling, вероятно, мало что значит для обычного рельса. У них гораздо больше проблем с масштабом и, вероятно, имеют давние проблемы со своим хранилищем данных, что не позволяет им масштабироваться за пределы их текущей реализации.

Beanstalkd является хорошей альтернативой, просто потому, что он работает как демон и имеет обертки на других языках сценариев (если вам случится изменить направление в будущем или иметь разные компоненты, написанные на других языках).

Этот link также имеет хорошее сравнение плюсов и минусов различных решений для рельсов.

Answer 5

Я использую background_job, который, как delayed_job, представляет собой базу данных на основе очереди.

База данных делает очередь OK, если вы не слишком много трафик.

Причина, по которой мне нравится background_job (и delayed_job), заключается в том, что они не требуют отдельного процесса. Они могут проходить через cron. Для меня это имеет ключевое значение, потому что мои потребности в передаче сообщений еще проще, чем мои скудные навыки sysadmin.

Answer 6

Я бы порекомендовал delayed-job как мертвое простое решение, если вы не ожидаете большой нагрузки. Плюсы: простой в настройке, простой мониторинг, простой код, не имеет внешних зависимостей. Раньше мы использовали ActiveMessaging (с ActiveMQ и stomp), но это было излишним для нашего проекта, поэтому мы просто переключились на delayed_job.

В любом случае, если вам нужно очень зрелого и быстрого решения, ActiveMQ - очень хороший выбор. Если вы не хотите тратить слишком много времени на поддержание полномасштабного решения для организации очередей сообщений, вам это действительно не нужно, delayed_job - это способ пойти. Вот good article о работе Scribd с ActiveMQ.

Answer 7

Возможно, сервер обмена сообщениями - RabbitMQ. Erlang coolness, AMQP, хорошие библиотеки Ruby.

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