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