Очереди сообщений в Ruby on Rails
https://stackoverflow.com/questions/721297
-
05-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Какие очереди сообщений люди используют для своих приложений Rails и что послужило движущей силой решения выбрать именно это.Влияет ли последняя реклама в Twitter по поводу падения Старлинга в очереди на дом на какие-либо существующие дизайнерские решения.
Я работаю над приложением, которому потребуется очередь сообщений для обработки некоторых фоновых задач, я мало что из этого делал, и большинство материалов, которые я видел в прошлом, касались Starling и Workling, и, честно говоря, приложение не очень большое, и этого решения, вероятно, было бы достаточно, но я хотел бы получить опыт интеграции наилучшего возможного решения, поскольку я уверен, что в какой-то момент я интегрирую его в более крупное приложение.
Какие очереди сообщений вы бы предложили для приложения Rails???
Редактировать:Спасибо за предложения, я собираюсь рассмотреть некоторые из них в эти выходные.
ОТРЕДАКТИРУЙТЕ Еще Раз:Я осмотрелся и немного ошеломлен выбором.Однако я собираюсь заняться интеграцией RabbitMQ с Workling в приложение, которое я создаю, тогда, если мне когда-нибудь понадобятся некоторые знания о быстрой очереди, я буду иметь это и знать, соответствует ли это моим потребностям.
Редактировать:Я все больше и больше убеждаюсь, что этот ди-джей мне просто подходит, и если я когда-нибудь "перерасту" его на сайт, я бы сказал, что я бы направился в Resque.
Редактировать:(декабрь 2014) Итак, прошло много времени с тех пор, как я задавал этот вопрос, но я вижу, что он все еще получает некоторые просмотры или голоса, поэтому я решил, что обновлю свой подход сейчас, когда дело дойдет до моего выбора фоновых работников.
На мой взгляд, в настоящее время лучшим способом запуска фоновых заданий в Ruby является использование Sidekiq.Многие люди действительно хвалили Sidekiq за то, что в нем есть рабочие потоки, а не процесс на одного рабочего, который может использовать значительно меньше памяти, чем подобные Resque, которые я использовал до Sidekiq.Это хорошо, но для меня это не было убийственной функцией.Используя Sidetiq с Sidekiq, планирование заданий настолько тривиально, что я переключился на него и никогда не оглядывался назад, это, безусловно, самое простое планирование заданий, которое я использовал, и сделало Sidekiq легким в использовании.
Решение
В качестве обновления - GitHub перешел на Resque на Redis вместо отложенного задания.Однако они по-прежнему рекомендуют delayed_job для небольших настроек:
Другие советы
Крис Ванстрат из github недавно был на SF Ruby meetup, рассказывая об их очереди.Они попробовали Starling, beanstalk и некоторые другие варианты, прежде чем остановились на Shopify delayed_job.Они довольно агрессивно используют фоновое оформление.
Вот такой запись в блоге за прошлый год это говорит об их переходе в ди-джеи.
Там, где я нахожусь сейчас, мы выпустили свой собственный несколько лет назад, но я позаимствовал несколько идей у ди-джея, чтобы улучшить управляемость.
Я бы порекомендовал отложенное задание это очень простое решение, если вы не ожидаете какой-либо большой нагрузки.Плюсы:простота настройки, простота мониторинга, простой код, не имеет никаких внешних зависимостей.Ранее мы использовали ActiveMessaging (с ActiveMQ и stomp), но это было излишеством для нашего проекта, поэтому мы переключились на delayed_job для его простоты.
В любом случае, если вам нужно очень продуманное и быстрое решение, ActiveMQ ( Активный q ) это очень хороший выбор.Если вы не хотите тратить слишком много времени на поддержку полномасштабного решения для организации очередей сообщений, которое вам на самом деле не нужно, delayed_job - это выход.Вот такой хорошая статья об опыте Scribd с ActiveMQ.
Вот несколько решений Ruby / Rails, одно или несколько из них могут подойти в зависимости от ваших потребностей:
http://xph.us/software/beanstalkd
http://rubyforge.org/forum/forum.php?forum_id=19781
http://backgroundrb.rubyforge.org
И размещенное решение от Amazon, которое создало бы отличную очередь для совместного использования между Ruby / Rails и другими компонентами более крупной системы:
Надеюсь, это поможет!
Сервер обмена сообщениями, на который вы, возможно, захотите перейти, - это RabbitMQ.Крутость Erlang, AMQP, хорошие библиотеки Ruby.
http://www.bestechvideos.com/2008/12/09/rabbitmq-an-open-source-messaging-broker-that-just-works
Рани Кеддо дал полезная презентация о Starling + Workling на RailsConf Europe в прошлом году.Он сравнил различные решения, доступные на тот момент.
Последний переход Twitter от Starling + Workling, вероятно, мало что значит для обычного приложения rails.У них гораздо больше проблем с масштабированием, и, вероятно, у них есть устаревшие проблемы с их хранилищем данных, которые не позволяют им масштабироваться дальше их текущей реализации.
Бобовый Стебельd это хорошая альтернатива, просто потому, что она запускается как демон и имеет оболочки на других языках сценариев (если вам случится изменить направление в будущем или у вас будут другие компоненты, написанные на других языках).
Это Ссылка также содержит хорошее сравнение плюсов и минусов различных доступных решений rails.
Я использую фоновое задание которые, как отложенная работа является очередью на основе базы данных.
База данных создает очередь OK до тех пор, пока вы не загружаете слишком много трафика.
Причина, по которой мне нравится background_job (и delayed_job), заключается в том, что они не требуют отдельного процесса.Они могут запускаться через cron.Для меня это имеет ключевое значение, потому что мои потребности в обмене сообщениями даже проще, чем мои скудные навыки системного администратора.
