Очереди сообщений в Ruby on Rails - PullRequest
38 голосов
/ 06 апреля 2009

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

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

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

РЕДАКТИРОВАТЬ: Спасибо за предложения, я собираюсь взглянуть на некоторые из них в эти выходные.

РЕДАКТИРОВАТЬ Еще раз: я осмотрелся вокруг и немного ошеломлен выбором. Однако я собираюсь интегрировать RabbitMQ с Workling в приложение, которое я создаю, и тогда, если мне когда-нибудь понадобятся знания о быстрой очереди, я получу это и буду знать, соответствует ли оно моим потребностям.

РЕДАКТИРОВАТЬ: Находить все больше и больше того, что DJ мне подходит просто отлично, если я когда-нибудь "перерасту" его на сайте, я бы сказал, что Resque - это то, куда я направляюсь.

РЕДАКТИРОВАТЬ: (декабрь 2014 г.) Так что я давно спрашивал об этом уже давно, но я вижу, что он по-прежнему получает несколько просмотров или несколько голосов, поэтому я решил, что обновлю свой подход сейчас, когда речь заходит о моем выборе фоновых работников.

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

Ответы [ 7 ]

16 голосов
/ 29 ноября 2009

В качестве обновления - GitHub перешел в Resque на Redis вместо отложенного задания. Однако они все еще рекомендуют delayed_job для небольших установок:

https://github.com/resque/resque

9 голосов
/ 16 апреля 2009

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

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

9 голосов
/ 06 апреля 2009

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

Вот блог за прошлый год , в котором говорится об их переходе на DJ.

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

4 голосов
/ 06 апреля 2009

Вот несколько решений для Ruby / 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

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

3 голосов
/ 16 апреля 2009

Сервер обмена сообщениями, к которому вы можете обратиться, это RabbitMQ. Erlang крутость, AMQP, хорошие Ruby libs.

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

2 голосов
/ 06 апреля 2009

Рани Кеддо сделал полезную презентацию о Starling + Workling на RailsConf Europe в прошлом году. Он сравнил различные решения, доступные в то время.

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

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

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

1 голос
/ 07 апреля 2009

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

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

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

...