ActiveMQ Artemis vs Apache Kafka: как выбрать брокер?
Содержание
Зачем нужна асинхронная коммуникация через сообщения? Синхронная коммуникация (REST или gRPC вызовы) имеет ряд недостатков. Во-первых, если один сервис сломается, то другой тоже не сможет работать. Во-вторых, если что-то пойдет не так с одним сервисом, это может нарушить работу всей системы. В-третьих, сервисы не справляются с пиковыми нагрузками.
Решить эти проблемы позволяет асинхронная коммуникация, при которой сервисы общаются через посредника – брокер. Этот способ обеспечивает слабую связность, буферизацию пиков и повышенную отказоустойчивость. Самые популярные технологии для асинхронного обмена данными – ActiveMQ Artemis и Apache Kafka
Что такое ActiveMQ Artemis
ActiveMQ Artemis — это высокопроизводительный, неблокирующий брокер сообщений с открытым исходным кодом. Он работает на языке программирования Java. Среди преимуществ ActiveMQ Artemis можно выделить высокую производительность с низкими задержками и высокой пропускной способностью. Брокер поддерживает стандарт JMS 2.0, что является ключевым для корпоративных сред. Брокер можно использовать как отдельно, так и интегрировать в приложения или создавать кластеры. ActiveMQ Artemis имеет встроенную поддержку множества протоколов, что делает его универсальным решением для интеграции с различными системами.
Как это работает? Клиенты подключаются к ActiveMQ Artemis по разным протоколам. Далее они встречают протокольные модули, которые переводят сообщение во внутренний формат брокера. Далее информация попадает в ядро, которое принимает решения: куда перенаправить сообщение и сохранять ли его на диск. Если требуется сохранение, то сообщение отправляется в журнал на диске. Вся цепочка действий оптимизирована для максимальной скорости.
[Клиенты (Producer/Consumer)]
|
| (Протоколы: Core, AMQP, MQTT...)
|
[Протокольные модули (Protocol Handlers)]
|
| (Внутренняя модель сообщений)
|
[Ядро Artemis (Non-blocking IO, Journal)]
|
| (Запись/Чтение)
|
[Файлы журнала (Journal files on Disk)]
Модели сообщений
ActiveMQ Artemis поддерживает две модели обмена сообщениями:
1. point-to-point, или очереди (queues). Сообщение отправляется в очередь и используется ровно одним потребителем. Такой подход подходит для распределения задач. Например, для обработки заказов есть несколько воркеров. Каждый заказ встает в очередь, любой свободный воркер забирает его в обработку. Таким образом, каждый заказ будет обработан только один раз.
2. publish-subscribe, или топики (topics). Сообщение публикуется в топик и доставляется потребителям, которые на него подписаны. Например, это удобно при рассылке уведомлений. Событие «Вышел новый пост в блоге» публикуется в топик, и все подписанные сервисы, такие как сервис рассылки на email, сервис push-уведомлений и сервис кэширования, получают копию сообщения и выполняют свои действия.
Гарантии доставки
ActiveMQ Artemis имеет богатый набор гарантий доставки.
- Auto Acknowledgement – брокер автоматически считает сообщение доставленным потребителю сразу после отправки.
- Client Acknowledgement – клиент должен явно подтвердить (ack), что сообщение обработано.
- Transactional – подтверждение доставки происходит в рамках транзакции, что позволяет объединить обработку нескольких сообщений или операций с базой данных в одну атомарную операцию.
- Durable Subscriptions – если потребитель отключается, все сообщения, отправленные в топик, сохраняются и доставляются при повторном подключении. Это особенно полезно в сценариях с нестабильным подключением.
Ядро
Высокую производительность ActiveMQ Artemis обеспечивает:
§ неблокирующий I/O. ActiveMQ Artemis использует Netty, чтобы не создавать поток на каждое соединение. Один поток обрабатывает тысячи одновременных подключений.
§ журналирующее хранилище. ActiveMQ Artemis сохраняет сообщение на диск и записывает его в конец последовательного журнала (append-only log). Это ускоряет работу с персистентностью.
§ внутренний пул сообщений. Вместо постоянного создания и удаления объектов сообщений в памяти, ActiveMQ Artemis использует их повторно, сводя к минимуму нагрузку на сборщик мусора в JVM.

Кластеризация
Чтобы добиться отказоустойчивости и масштабирования, ActiveMQ Artemis можно объединять в кластеры с помощью следующих подходов: .
§ Master-slave репликация. Ведущий (master) и ведомый (slave) сервер используют общий диск в режиме shared store. При падении ведущего сервера, ведомый сервер подхватывает его файлы и продолжает работать. В режиме репликации ведомый сервер постоянно синхронно копирует журнал с ведущим сервером по сети, таким образом, необходимость в общем диске отпадает.
§ Симметричный кластер. В этом случае несколько брокеров равноправно взаимодействуют между собой. Сообщение, пришедшее на один узел, может быть перенаправлено потребителю на другом узле. Этот метод больше ориентирован на распределение нагрузки, чем на обеспечение отказоустойчивости.
Что такое Apache Kafka
Apache Kafka представляет собой распределенную платформу для потоковой обработки данных. В первую очередь, это распределенный надежный журнал событий (commit log).
Как это работает? Данные организуются в топики. Каждый топик делится на партиции для горизонтального масштабирования. Партиции распределяются по разным серверам кластера. Каждое сообщение в партиции имеет свой уникальный офсет –последовательный номер. Потребители объединяются в consumer groups. Каждая партиция топика потребляется только одним потребителем из группы, что позволяет масштабировать обработку.
Чем отличаются ActiveMQ Artemis и Apache Kafka
Между ActiveMQ Artemis и Apache Kafka есть фундаментальная разница:
§ ActiveMQ Artemis работает по принципу «умный брокер / глупый клиент». Брокер в этой системе управляет очередями, подписками и маршрутизацией сообщений. Клиенты остаются относительно пассивными участниками процесса: им не нужно беспокоиться о логике доставки сообщений, достаточно просто подключиться к брокеру и получать данные.
§ Apache Kafka придерживается обратного подхода и работает по принципу «глупый брокер / умный клиент». Брокер прост и не отслеживает, какие сообщения были уже прочитаны. Его задача – хранить упорядоченную последовательность (лог) сообщений. Вся логика выбора ложится на плечи клиента. Клиент самостоятельно отслеживает свой текущий офсет и решает, с какого места продолжить чтение. Такой подход делает клиентов более сложными в разработке, но при этом упрощает и масштабирует работу брокера.
Исходя из этой разной философии, вытекают все технические различия (см. Таблица 1).
Таблица 1. Сравнительная таблица: ActiveMQ Artemis vs Apache Kafka
|
Критерии |
ActiveMQ Artemis |
Apache Kafka |
|
Масштабирование |
Вертикальное + Master-Slave + Symmetric Cluster |
Горизонтальное (через партиции и добавление брокеров) |
|
Основная модель |
Брокер сообщений (Message Broker) |
Распределенный лог (Distributed Log) |
|
Подписка |
Гибкая: Durable, Non-Durable, Selectors |
Только через Consumer Groups |
|
Приоритет |
Низкая задержка (Low Latency) |
Высокая пропускная способность (High Throughput) |
|
Протоколы |
Множество (AMQP, MQTT, STOMP, OpenWire) |
Собственный бинарный протокол (и Kafka Connect) |
|
Семантика доставки |
Богатые (JMS): транзакции, ACK, TTL |
"At-least-once", "Exactly-once" для потоков |
|
Сложность |
Проще в развертывании и управлении для классических сценариев |
Выше, требует настройки ZooKeeper, мониторинга множества компонентов |
|
Хранение |
Журналирование, сообщения удаляются после доставки и подтверждения |
Сообщения хранятся заданное время (дни, недели), независимо от потребления |
|
Экосистема |
Брокер + Клиенты |
Огромная: Kafka Connect, Kafka Streams, Schema Registry, ksqlDB |
Также есть важные нюансы в производительности под нагрузкой.
- Задержка vs пропускная способность. ActiveMQ Artemis ориентирован на минимальные задержки и оптимизирован для быстрой доставки одного сообщения. Apache Kafka же специализируется на обработке больших объемов данных в пачках. Несмотря на то, что задержка на одно сообщение у Apache Kafka выше, стоимость обработки одного сообщения в пачке из тысяч крайне низка, что обеспечивает высокую пропускную способность.
- Персистентность. В обоих брокерах сообщений данные синхронно записываются в журнал на диск для надежности. Но Apache Kafka,заточена на последовательную запись больших пачек данных, что делает эту операцию более эффективной при работе с огромными объемами информации.
- Масштабирование. ActiveMQ Artemis масштабируется преимущественно вертикально (более мощный сервер) и с помощью кластеров для обеспечения отказоустойчивости. Apache Kafka же изначально спроектирован для горизонтального масштабирования (если добавить новый брокер в кластер и увеличить количество партиций у топика, то пропускная способность линейно возрастет).
Когда выбирать ActiveMQ Artemis
Стоит выбрать ActiveMQ Artemis, если вам нужны:
- строгие гарантии JMS, транзакции, TTL-сообщений;
- низкая задержка;
- универсальный шлюз для разнородных клиентов (MQTT, AMQP, STOMP);
- классические очереди задач, где каждое задание должно быть обработано только один раз.
- простая операционная модель для развертывания и поддержки, более простая конфигурация и запуск.
Когда выбирать Apache Kafka
Стоит выбрать Apache Kafka, если вам нужны:
- потоковая обработка данных (аналитика в реальном времени, мониторинг, агрегация показателей);
- долгосрочное хранение потока событий. Способность брокера Apache Kafka хранить историю – его ключевое преимущество;
- создание data pipeline для больших данных – для перекачки огромных объемов данных между системами, например, из логов приложений в Hadoop или Spark;.
- разработка событийно-ориентированной архитектуры (event-driven architecture), где важно иметь возможность вернуться к любому моменту и воспроизвести все события;
- линейная масштабируемость для работы с огромными нагрузками.
Выводы
Важно отметить, что ActiveMQ Artemis и Apache Kafka не конкурируют между собой. Они решают разные задачи и по-разному устроены.
ActiveMQ Artemis представляет собой современный и высокопроизводительный классический брокер сообщений. Он идеально подходит для создания отзывчивых и надежных систем, где критичны каждая миллисекунда и строгие гарантии доставки данных.
Apache Kafka, в свою очередь, является мощной платформой для обработки потоковых данных и работы с событиями. Она оптимальна для построения масштабируемых систем передачи данных, где важна возможность восстановления и повторного воспроизведения событий, а не их мгновенная доставка.
Выбор между этими брокерами зависит от конкретных требований проекта. Необходимо определить, что важнее: минимизация задержек (latency) или обеспечение высокой пропускной способности (throughput). Также следует учитывать необходимость транзакционной поддержки JMS или возможность восстановления событий за прошлые периоды.
Другие материалы
компании