ActiveMQ или RabbitMQ или ZeroMQ или

Редактировать: Мой первоначальный ответ был сосредоточен на AMQP. Я решил переписать его, чтобы предложить более широкий взгляд на тему.

Эти 3 технологии обмена сообщениями имеют разные подходы к построению распределенных систем:

RabbitMQ — одна из ведущих реализаций протокола AMQP (наряду с Apache Qpid). Поэтому он реализует архитектуру брокера, что означает, что сообщения ставятся в очередь на центральном узле перед отправкой клиентам. Такой подход делает RabbitMQ очень простым в использовании и развертывании, поскольку расширенные сценарии, такие как маршрутизация, балансировка нагрузки или постоянная организация очередей сообщений, поддерживаются всего несколькими строками кода. Однако это также делает его менее масштабируемым и «медленным», потому что центральный узел увеличивает задержку, а конверты сообщений довольно велики.

ZeroMq — это очень легкая система обмена сообщениями, специально разработанная для сценариев с высокой пропускной способностью и малой задержкой, таких как те, которые вы можете найти в финансовом мире. Zmq поддерживает множество расширенных сценариев обмена сообщениями, но, в отличие от RabbitMQ, вам придется реализовывать большинство из них самостоятельно, комбинируя различные части фреймворка (например, сокеты и устройства). Zmq очень гибкий, но вам придется изучить примерно 80 страниц руководства (которое Я рекомендую прочитать всем, кто пишет распределенную систему, даже если вы не используете Zmq), прежде чем сможете делать что-то более сложное, чем отправка сообщений между двумя узлами.

ActiveMQ занимает промежуточное положение. Как и Zmq, его можно развернуть как с брокерской, так и с P2P-топологией. Как и в случае с RabbitMQ, сложные сценарии реализовать проще, но обычно это происходит за счет снижения производительности. Это швейцарский армейский нож обмена сообщениями :-).

Наконец, все 3 продукта:

• иметь клиентские API для наиболее распространенных языков (C++, Java, .Net, Python, Php, Ruby, …)
• иметь сильную документацию
• активно поддерживаются

Почему вы пропустили Sparrow, скворец, пустельга, Amazon SQS, Beanstalkd, Kafka, IronMQ ?

Серверы очереди сообщений

Серверы очередей сообщений доступны на разных языках: Erlang (RabbitMQ), C (beanstalkd), Ruby (Starling или Sparrow), Scala (Kestrel, Kafka) или Java (ActiveMQ). Краткий обзор можно найти здесь

Воробей

• автор Алекс Маккоу
• Sparrow — это облегченная очередь, написанная на Ruby и «говорящая с memcache».

Скворец

• написано Блейном Куком в Твиттере
• Starling — это сервер очереди сообщений на основе MemCached.
• написано на руби
• сохраняет задания в памяти (очередь сообщений)
• документация: несколько хороших руководств, например, railscast о скворцах и рабочих или эта запись в блоге о скворцах

Пустельга

• автор Роби Пойнтер
• Клон Starling, написанный на Scala (порт Starling с Ruby на Scala)
• Очереди хранятся в памяти, но регистрируются на диске

КроликMQ

• RabbitMQ — это сервер очереди сообщений в Erlang.
• сохраняет задания в памяти (очередь сообщений)

Апач ActiveMQ

• ActiveMQ — брокер сообщений с открытым исходным кодом на Java.

Бобовый стебель

• написано Philotic, Inc. для улучшения времени отклика приложения Facebook.
• служба рабочей очереди в памяти, в основном написанная на C
• Документ: http://nubyonrails.com/articles/about-this-blog-beanstalk-messaging-queue

Amazon SQS

• Служба простых очередей Amazon

Кафка

• Написано в LinkedIn на Scala
• Используется LinkedIn для разгрузки обработки всех страниц и других просмотров.
• По умолчанию используется сохраняемость, для горячих данных используется дисковый кеш ОС (имеет более высокую пропускную способность, чем любое из вышеперечисленных устройств с включенной сохраняемостью).
• Поддерживает как онлайн, так и автономную обработку

ZMQ

• Библиотека сокетов, которая действует как среда параллелизма.
• Быстрее, чем TCP, для кластерных продуктов и суперкомпьютеров
• Переносит сообщения через inproc, IPC, TCP и многоадресную рассылку.
• Соедините N-to-N через разветвление, pubsub, конвейер, запрос-ответ
• Асинхронный ввод-вывод для масштабируемых многоядерных приложений для передачи сообщений

ОрелMQ

• EagleMQ — это высокопроизводительный и легкий менеджер очередей с открытым исходным кодом.
• Написано на С
• Хранит все данные в памяти и поддерживает постоянство.
• У него есть свой протокол. Поддерживает работу с очередями, маршрутами и каналами.

IronMQ

• IronMQ
• Написано на Go
• Полностью управляемая служба очереди
• Доступен как в облачной, так и в локальной версии

Я надеюсь, что это будет полезно для нас. источник

Больше информации, чем вы хотели бы знать:

http://wiki.secondlife.com/wiki/Message_Queue_Evaluation_Notes

ОБНОВИТЬ

Просто уточняю то, что Пол добавил в комментарии. Упомянутая выше страница мертва после 2010 года, так что читайте ее с долей скептицизма. Много чего поменяно за 3 года.

Это действительно зависит от вашего варианта использования.

Сравнивать 0MQ с ActiveMQ или RabbitMQ некорректно. ActiveMQ и RabbitMQ — это системы обмена сообщениями, которые требуют установки и администрирования. Они предлагают гораздо больше функций, чем ZeroMQ. У них есть настоящие постоянные очереди, поддержка транзакций и т. д.

ZeroMQ — это облегченная реализация сокета, ориентированная на сообщения. Он также подходит для внутрипроцессного асинхронного программирования. Можно запустить «Корпоративную систему обмена сообщениями» поверх ZeroMQ, но вам придется многое реализовать самостоятельно.

So:

ActiveMQ, RabbitMQ, Websphere MQ и MSMQ — это «Очереди корпоративных сообщений».

ZeroMQ — это библиотека IPC, ориентированная на сообщения.

Сравните RabbitMQ и ActiveMQ здесь. По умолчанию ActiveMQ настроен так, чтобы гарантировать доставку сообщений, что может создать впечатление его медленности по сравнению с менее надежными системами обмена сообщениями. Вы всегда можете изменить конфигурацию для повышения производительности, если хотите, и получить по крайней мере такую ​​же хорошую производительность, как и любая другая система обмена сообщениями. По крайней мере, у вас есть такая возможность. На форумах и в FAQ по ActiveMQ можно найти много информации о настройке масштабирования, производительности и высокой доступности. Кроме того, ActiveMQ будет поддерживать AMQP 1.0, когда спецификация будет завершена, вместе с другими форматами проводов, такими как STOMP.

Еще одним плюсом ActiveMQ является то, что это проект Apache, поэтому в сообществе разработчиков есть разнообразие, и оно не привязано к одной компании.

Я не использовал ActiveMQ или RabbitMQ, но использовал ZeroMQ. Насколько я вижу, большая разница между ZeroMQ и ActiveMQ и т. д. заключается в том, что 0MQ не имеет посредников и не имеет встроенной надежности доставки сообщений. Если вы ищете простой в использовании API для обмена сообщениями, поддерживающий множество шаблонов обмена сообщениями, транспортов, платформ и языковых привязок, то 0MQ определенно стоит вашего внимания. Если вы ищете полнофункциональную платформу для обмена сообщениями, то 0MQ может вам не подойти.

См. www.zeromq.org/docs:cookbook, где можно найти множество примеров использования 0MQ.

Я успешно использую 0MQ для передачи сообщений в приложении для мониторинга потребления электроэнергии (см. http://rwscott.co.uk/2010/06/14/currentcost-envi-cc128-part-1/)

Я использую ZeroMQ. Я хотел простую систему передачи сообщений, и мне не нужно усложнение брокера. Мне также не нужна огромная корпоративная система, ориентированная на Java.

Если вам нужна быстрая и простая система, и вам нужна поддержка нескольких языков (я использую C и .net), я бы порекомендовал обратить внимание на 0MQ.

Я могу только добавить свои 2 цента по поводу ActiveMQ, но так как это один из самых популярных:

Язык, на котором вы хотите писать, может быть важен. Хотя у ActiveMQ есть клиент для большинства, их реализация на C# далека от завершения по сравнению с библиотекой Java.

Это означает, что некоторые базовые функции ненадежны (протокол аварийного переключения, который... ну... в некоторых случаях дает сбой, отсутствие поддержки повторной доставки), а других просто нет. Поскольку .NET, похоже, не так уж важен для проекта, разработка идет довольно медленно, и, похоже, нет никакого плана выпуска. Ствол часто ломается, поэтому, если вы думаете об этом, вы можете подумать о том, чтобы внести свой вклад в проект, если хотите, чтобы дела шли вперед.

Кроме того, есть сам ActiveMQ, у которого есть много хороших функций, но есть и очень странные проблемы. Мы используем версию activemq Fuse (Progress) из соображений стабильности, но даже в этом случае есть пара странных «ошибок», о которых следует помнить:

• Брокеры, которые в некоторых случаях перестают отправлять сообщения
• Ошибки журнала, из-за которых в очереди отображаются сообщения, которых больше нет (они не доставляются потребителю, но все же)
• Приоритет до сих пор не реализован (находится в списке проблем с самого начала человечества)
• и т.д.

В общем, это довольно хороший продукт, ЕСЛИ вы можете жить с его проблемами:

А) не боятся активно включаться при использовании .NET
Б) разрабатывать на java ;-)

ZeroMQ действительно без очередей! Это действительно ошибка! В нем нет очередей, тем, настойчивости, ничего! Это всего лишь промежуточное ПО для API сокетов. Если это то, что вы ищете круто! иначе забудь! это не похоже на activeMQ или rabbitmq.

Сравнение функций и производительности RabbitMQ ActiveMQ и QPID приведено по адресу
http://bhavin.directi.com/rabbitmq-vs-apache-activemq-vs-apache-qpid/

Лично я пробовал все три вышеперечисленных. По моему мнению, RabbitMQ является лучшим с точки зрения производительности, но у него нет вариантов аварийного переключения и восстановления. ActiveMQ имеет больше возможностей, но работает медленнее.

Обновление: HornetQ также является вариантом, на который вы можете обратить внимание, это жалоба JMS, лучший вариант, чем ActiveMQ если вы ищете решение на основе JMS.

Я написал о своем первом опыте использования AMQP, Qpid и ZeroMQ здесь: http://ron.shoutboot.com/2010/09/25/is-ampq-for-you/

Мое субъективное мнение состоит в том, что AMQP хорош, если вам действительно нужны средства постоянного обмена сообщениями и вы не слишком обеспокоены тем, что брокер может стать узким местом. Кроме того, клиент C++ в настоящее время отсутствует для AMQP (Qpid не получил моей поддержки, однако не уверен в клиенте ActiveMQ), но, возможно, работа продолжается. ZeroMQ может быть иным.

Я использую ActiveMQ в производственной среде уже около 3 лет. Несмотря на то, что он выполняет свою работу, согласование версий клиентских библиотек, которые работают правильно и не содержат ошибок, может быть проблемой. В настоящее время мы собираемся перейти на RabbitMQ.

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

Стив провел обширное нагрузочное и стресс-тестирование ActiveMQ, RabbitMQ и т. д. ActiveMQ на самом деле довольно медленный (намного медленнее, чем Kestrel), RabbitMQ постоянно дает сбой при слишком большом количестве производителей и слишком малом количестве потребителей.

Однако изначально у вас, вероятно, не будет нагрузки, похожей на Twitter :)

Немногие приложения имеют столько настраиваемых конфигураций, сколько ActiveMQ. Некоторые особенности, которые выделяют ActiveMQ:

Настраиваемый размер предварительной выборки. Настраиваемая многопоточность. Настраиваемый отказоустойчивый режим. Настраиваемое административное уведомление производителей. ... подробности по адресу:

http://activemq.net/blog http://activemq.apache.org

Если вас также интересуют коммерческие реализации, обратите внимание на Nirvana на моих каналах.

Nirvana широко используется в индустрии финансовых услуг для крупномасштабной торговли с малой задержкой и платформ распределения цен.

Существует поддержка широкого спектра клиентских языков программирования в корпоративных, веб- и мобильных доменах.

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

Nirvana можно загрузить бесплатно для целей разработки.

Эйби, все зависит от твоего варианта использования. Вместо того, чтобы полагаться на чью-то учетную запись их варианта использования, не стесняйтесь опубликовать свой вариант использования в списке rabbitmq-discuss. Спросив в твиттере, вы тоже получите ответы. С наилучшими пожеланиями, Алексей

Что касается ZeroMQ, также известного как 0MQ, как вы, возможно, уже знаете, это тот, который будет приносить вам наибольшее количество сообщений в секунду (в последний раз, когда я проверял, их было около 4 миллионов в секунду на их ref-сервере), но, как вы, возможно, уже знаете, документация отсутствует. Вам будет трудно найти, как запустить сервер(ы), не говоря уже о том, как их использовать. Я предполагаю, что отчасти поэтому никто еще не сообщил о 0MQ.

Развлекайся!