У меня нет предыдущего опыта работы с * MQ, и я хочу расширить знания о JMS и очередях сообщений в целом. Таким образом, мне интересно, следует ли мне начать с ActiveMQ или просто «игнорировать» его и начать с обучения Apollo. Является ли Apollo таким же полным, как ActiveMQ? Реализует ли он JMS 2.0 (я вижу, что ActiveMQ застрял с 1.1)? Я буду упускать что-то действительно важное?
Кроме того, как Kafka сравнивается с этими двумя решениями?
Apache ActiveMQ - отличная рабочая лошадка, полная функций и приятных вещей. Это не самое быстрое программное обеспечение MQ, но достаточно быстрое для большинства случаев использования. Среди функций - гибкая кластеризация, переключение при отказе, интеграция с различными серверами приложений, безопасность и т. Д.
Apache Apollo - это попытка написать новое ядро для ActiveMQ, способное справиться с большим количеством клиентов и сообщений. В нем нет всех хороших и удобных функций ActiveMQ, но он масштабируется намного лучше. Apache Apollo - это действительно быстрая реализация MQ, если вы предоставите ему большой многоядерный сервер и тысячи одновременных подключений. Он имеет приятный и простой пользовательский интерфейс, но не является универсальным решением.
Похоже, что продолжается попытка объединить ряд функций ActiveMQ с HornetQ под названием ActiveMQ Artemis. HornetQ поддерживает JMS2.0, поэтому я скромно предполагаю, что он, скорее всего, появится в ActiveMQ 6.x.
Кафка - другой зверь. Это очень простой брокер сообщений, предназначенный для максимально быстрого масштабирования постоянной публикации (тем) на нескольких серверах. Для развертываний малого и среднего размера Kafka, вероятно, не лучший вариант. У него также есть способ сделать что-то для достижения высокой пропускной способности, поэтому вам придется много торговать с точки зрения гибкости, чтобы получить высокую распределенную пропускную способность. Если вы новичок в области MQ и брокеров, я полагаю, что Kafka - излишек. С другой стороны - если у вас есть кластер серверов приличного размера и вы не знаете, как протолкнуть через него как можно больше сообщений - попробуйте Kafka!
Это старый вопрос, но здесь я дам более современный ответ.
РЕДАКТИРОВАТЬ: Выпуск 2.3.0 Apache Artemis произошел ~ 5 сентября 2017 года. Так что, похоже, на данный момент он прогрессирует. Но (ссылка) журнал изменений по-прежнему кажется слишком пугающим.
Я провожу тест производительности ActiveMQ, Apollo, HornetQ при непостоянном сценарии и постоянном сценарии, я думаю, вам будет полезно выбрать, какой из них следует использовать, ссылка, как показано ниже: http://hiramchirino.com/jms-benchmark/ubuntu-2600k/index.html.
Apache Kafka можно охарактеризовать как «платформу распределенной потоковой передачи», где ActiveMQ, MOM (промежуточное ПО, ориентированное на обмен сообщениями), является «Брокер сообщений общего назначения».
Kafka делает одно, и одно очень хорошо: в архитектуре публикации / подписки (публикации / подписки) сообщения записываются в темы (журналы, распределяемые по разделам), которые затем потребители потребляют из по зачету. Kafka, созданный для облака с очень высокой пропускной способностью, делает упор на этом, и в наши дни идеальный вариант для асинхронного обмена сообщениями.
ActiveMQ поддерживает семантику pub / sub и точка-точка. В последнем случае очередь обрабатывает отдельные сообщения между одним производителем и конкретным потребителем. Это, как и pub / sub, является асинхронным, но работает несколько иначе: если потребитель получает сообщение в очереди, но не может его подтвердить, сообщение затем отправляется другому потребителю. ActiveMQ также поддерживает несколько протоколов обмена сообщениями, включая AMQP, STOMP, JMS, CAMEL и MQTT.
Хотя Apache Kafka может быть идеальным помощником для простой асинхронной связи; Некоторые, похоже, предпочитают ActiveMQ для более сложных шаблонов маршрутизации, таких как корпоративные шаблоны, однако многие утверждают, что Kafka является улучшением по сравнению с ActiveMQ, по таким причинам, как более высокая пропускная способность, более эффективное управление разделы для журналов / тем и более тонкие ACL для потребителей, использующих тему.
