ActiveMQ или RabbitMQ или ZeroMQ или
Нам было бы интересно услышать любые впечатления от плюсов и минусов ActiveMQ против RabbitMQ против ZeroMQ. Также приветствуется информация о любых других интересных очередях сообщений.
Редактировать: Мой первоначальный ответ был сосредоточен на AMQP. Я решил переписать его, чтобы предложить более широкий взгляд на эту тему.
Эти 3 технологии обмена сообщениями имеют разные подходы к построению распределенных систем:
RabbitMQ является одной из ведущих внедрений протокола AMQP (наряду с Apache Qpid). Поэтому он реализует архитектуру брокера, а это означает, что сообщения отправляются в очередь на центральный узел перед отправкой клиентам. Этот подход делает RabbitMQ очень простым в использовании и развертывании, поскольку расширенные сценарии, такие как маршрутизация, балансировка нагрузки или постоянная очередь сообщений, поддерживаются всего несколькими строками кода. Однако он также делает его менее масштабируемым и «медленным», потому что центральный узел добавляет латентность, а конверты сообщений довольно велики.
ZeroMq – очень легкая система обмена сообщениями, специально разработанная для сценариев с высокой пропускной способностью и низкой задержкой, таких как тот, который вы можете найти в финансовом мире. Zmq поддерживает множество передовых сценариев обмена сообщениями, но, вопреки RabbitMQ, вам придется реализовать большинство из них, объединив различные части фреймворка (например, сокеты и устройства). Zmq очень гибкий, но вам нужно изучить 80 страниц или около того руководства (которое я рекомендую читать для любого, кто пишет распределенную систему, даже если вы не используете Zmq), прежде чем сможете сделать что-нибудь более сложное, чем отправлять сообщения между двумя сверстниками.
ActiveMQ находится в середине. Как и Zmq, он может быть развернут с использованием как брокерских, так и P2P-топологий. Как и RabbitMQ, проще реализовать расширенные сценарии, но обычно это связано с затратами на производительность. Это швейцарский армейский нож обмена сообщениями :-).
Наконец, все 3 продукта:
- иметь клиентский apis для наиболее распространенных языков (C ++, Java, .Net, Python, Php, Ruby, …)
- иметь прочную документацию
- активно поддерживаются
Почему вы пропустили Воробей , Старлинг , Kestrel , Amazon SQS , Beanstalkd , Kafka , IronMQ ?
Серверы очереди сообщений
Серверы очереди сообщений доступны на разных языках: Erlang (RabbitMQ), C (beanstalkd), Ruby (Starling или Sparrow), Scala (Kestrel, Kafka) или Java (ActiveMQ). Краткий обзор можно найти здесь
Воробей
- написанный Алексом Маккау
- Sparrow – это легкая очередь, написанная на Ruby, которая «говорит memcache»,
Скворец
- написанный Блейн Кук в Twitter
- Starling – это сервер очереди сообщений на основе MemCached
- написанный на Ruby
- сохраняет задания в памяти (очередь сообщений)
- документация: некоторые хорошие учебные пособия, например, railscast о скворцах и workling или это сообщение в блоге о скворцах
Пустельга
- написанный Робей Пойнтером
- Скворец клона, написанный в Скале (порт Старлинг из Руби в Скала)
- Очереди хранятся в памяти, но записываются на диск
RabbitMQ
- RabbitMQ – сервер очереди сообщений в Erlang
- сохраняет задания в памяти (очередь сообщений)
Apache ActiveMQ
- ActiveMQ – это брокер сообщений с открытым исходным кодом в Java
Beanstalkd
- написанный Philotic, Inc., чтобы улучшить время отклика приложения Facebook
- служба записи в память в основном, написанная на C
- Документ: http://nubyonrails.com/articles/about-this-blog-beanstalk-messaging-queue
Amazon SQS
- Служба простой очереди Amazon
Кафка
- Написано в LinkedIn в Scala
- Используется LinkedIn для разгрузки обработки всех страниц и других видов
- По умолчанию для использования persistence используется кеш-память ОС для горячих данных (имеет более высокую пропускную способность, чем любой из вышеперечисленных с включенной поддержкой)
- Поддержка как on-line, так и оффлайн-обработки
ZMQ
- Библиотека сокетов, которая действует как среда параллелизма
- Быстрее, чем TCP, для кластеризованных продуктов и суперкомпьютеров
- Переносит сообщения через inproc, IPC, TCP и многоадресную рассылку
- Подключите N-to-N через разветвление, pubsub, конвейер, запрос-ответ
- Asynch I / O для масштабируемых многоядерных приложений для передачи сообщений
EagleMQ
- EagleMQ – это высокопроизводительный и легкий менеджер очередей с открытым исходным кодом.
- Написано на C
- Сохраняет все данные в памяти и поддерживает постоянство.
- У него есть собственный протокол. Поддерживает работу с очередями, маршрутами и каналами.
IronMQ
- IronMQ
- Написано в Go
- Полностью управляемая служба очереди
- Доступны как в виде облачной версии, так и на основе
Надеюсь, что это будет полезно для нас. источник
Больше информации, чем вы хотели бы знать:
http://wiki.secondlife.com/wiki/Message_Queue_Evaluation_Notes
ОБНОВИТЬ
Просто уточняю, что Павел добавил в комментарии. Вышеупомянутая страница мертва после 2010 года, поэтому читайте ее щепоткой соли. За три года было изменено много вещей.
Это действительно зависит от вашего прецедента.
Сравнение 0MQ с ActiveMQ или RabbitMQ несправедливо. ActiveMQ и RabbitMQ – это системы обмена сообщениями, для которых требуется установка и администрирование. Они предлагают больше, чем ZeroMQ. У них есть реальные постоянные очереди, поддержка транзакций и т. Д.
ZeroMQ – это облегченная реализация, ориентированная на сокет. Он также подходит для асинхронного программирования в процессе. Можно запустить «Enterprise Messaging System» над ZeroMQ, но вам придется много реализовывать самостоятельно.
Так:
ActiveMQ, RabbitMQ, Websphere MQ и MSMQ – это «очереди корпоративных сообщений»,
ZeroMQ – это библиотека IPC, ориентированная на сообщения.
Здесь есть сравнение между RabbitMQ и ActiveMQ. Исходя из этого, ActiveMQ настроен так, чтобы гарантировать доставку сообщений, что может дать впечатление медленное по сравнению с менее надежными системами обмена сообщениями. Вы всегда можете изменить конфигурацию производительности, если хотите, и получить как минимум хорошую производительность, чем любая другая система обмена сообщениями. По крайней мере, у вас есть этот вариант. На форумах и часто задаваемых частотах ActiveMQ есть много информации о настройке масштабирования, производительности и высокой доступности. Кроме того, ActiveMQ будет поддерживать AMQP 1.0, когда спецификация будет завершена, вместе с другими форматами проводов, такими как STOMP.
Еще одним плюсом для ActiveMQ является его проект Apache, поэтому в сообществе разработчиков есть разнообразие, и оно не привязано к одной компании.
Я не использовал ActiveMQ или RabbitMQ, но использовал ZeroMQ. Большая разница, поскольку я вижу это между ZeroMQ и ActiveMQ и т. Д., Заключается в том, что 0MQ является брокерским и не имеет встроенной надежности для доставки сообщений. Если вы ищете простой в использовании API обмена сообщениями, поддерживающий многие шаблоны обмена сообщениями, транспорты, платформы и языковые привязки, то 0MQ определенно стоит посмотреть. Если вы ищете полноценную платформу обмена сообщениями, то 0MQ может не соответствовать счету.
См. http://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-библиотекой.
Это означает, что некоторые базовые функции являются flaky (протокол с отказом, который … ну … в некоторых случаях не удается, без поддержки redelivery), а другие просто нет. Поскольку .NET, похоже, не так важен для проекта, разработка довольно медленная, и, похоже, нет плана выпуска. Магистральная сеть часто ломается, поэтому, если вы это рассмотрите, вы можете подумать о том, чтобы внести вклад в проект, если хотите, чтобы все продолжалось.
Тогда есть сам ActiveMQ, который имеет много приятных функций, но некоторые очень странные проблемы. Мы используем версию activerq Fuse (Progress) для стабильности, но даже тогда есть несколько странных «ошибок», которые вы хотите иметь в виду:
- Брокеры, которые перестают отправлять сообщения в некоторых случаях
- Ошибки журнала, делающие очереди, показывают сообщения, которых больше нет (они не доставляются потребителю, но все же)
- Приоритет все еще не реализован (находится в списке проблем с самого начала человеческого рода)
- и т.д.
Все и все, это довольно хороший продукт, если вы можете жить со своими проблемами:
A) не боятся активно участвовать при использовании .NET.
B) развиваться в java 😉
ZeroMQ действительно с нулевыми очередями! Это действительно ошибка! Это не hav очереди, темы, настойчивость, ничего! Это лишь промежуточное ПО для 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, это:
Настраиваемый размер предварительной выборки. Настраиваемая резьба. Конфигурируемый переход на другой ресурс. Настраиваемые административные уведомления производителей. … подробнее:
Аби, все сводится к твоему прецеденту. Вместо того, чтобы полагаться на чужой отчет о своем случае использования, не стесняйтесь публиковать свой вариант использования в списке rabbitmq-discuss. Если вы попросите в Twitter, вы получите ответы. С наилучшими пожеланиями, alexis
О ZeroMQ aka 0MQ, как вы уже могли знать, это то, что вы получите наибольшее количество сообщений в секунду (они были около 4 миллионов в секунду на их сервере ref в последний раз, когда я проверял), но, как вы уже могли уже знать, документация отсутствует. Вам будет трудно найти, как запустить сервер (ы), не говоря уже о том, как их использовать. Наверное, это отчасти потому, что никто еще не внес около 0MQ.
Повеселись!
Если вы также заинтересованы в коммерческих реализациях, вы должны взглянуть на Нирвану из моих каналов .
Nirvana широко используется в отрасли финансовых услуг для широкомасштабных платформ с низкой задержкой и распределения цен.
Существует поддержка широкого спектра языков программирования клиентов на корпоративном, веб-и мобильном доменах.
Возможности кластеризации чрезвычайно продвинуты и заслуживают внимания, если для вас важна прозрачность HA или балансировка нагрузки.
Nirvana можно скачать бесплатно для целей развития.