Добрый день. Сегодня мы поговорим о двух мощных технологиях для асинхронного обмена данными — ActiveMQ Artemis и Apache Kafka. Мы разберемся, что они из себя представляют, как устроены под капотом, и главное — в каких ситуациях стоит выбрать одну, а в каких другую.

Наш план на сегодня довольно насыщенный. Мы начнем с того, почему вообще все пришли к асинхронному общению сервисов. Затем подробно разберем ActiveMQ Artemis — что это и какие задачи решает. Заглянем в его техническую архитектуру, чтобы понять источник его производительности. После этого мы кратко вспомним основы Apache Kafka, чтобы затем перейти к самому интересному — детальному сравнению. Мы составим четкие рекомендации, поговорим о нагрузочных характеристиках и подведем итоги.

Зачем всё это?

Давайте начнем с основ. Всем нам знакома синхронная коммуникация, например, REST или gRPC вызовы. Сервис А вызывает сервис Б и ждет ответа. Но у этого подхода есть серьезные недостатки: во-первых, это жёсткая связность — если сервис Б упал, то сервис А тоже скорее всего перестанет работать корректно. Во-вторых, каскадные сбои — одна ошибка может потянуть за собой всю цепочку. В-третьих, пиковые нагрузки — если на сервис Б обрушится шквал запросов, он не справится, и запросы начнут падать.

Решение этих проблем — асинхронная коммуникация через сообщения. Вместо прямых вызовов сервисы общаются через посредника — брокер. Сервис А отправляет сообщение и сразу забывает о нем, продолжая свою работу. Сервис Б обработает сообщение, когда будет готов. Это дает нам слабую связность, буферизацию пиков и повышенную отказоустойчивость. И двумя самыми популярными решениями в JVM-мире для этого как раз и являются Artemis и Kafka.

Что такое ActiveMQ Artemis?

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

Какие же цели ставили перед собой его создатели?

• Во-первых, это высочайшая производительность — как низкая задержка, так и высокая пропускная способность.

• Во-вторых, полная поддержка стандарта JMS 2.0, что критично для enterprise-сред.

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

• И в-четвертых, поддержка множества протоколов "из коробки", что делает его универсальным шлюзом для разных систем.

Ключевые концепции Artemis 

Модели сообщений

Artemis, как и любой классический брокер, поддерживает две основные модели обмена сообщениями.

Первая — Point-to-Point, или очереди (Queues). В этой модели сообщение отправляется в очередь и потребляется ровно одним потребителем. Это идеальная модель для распределения задач. Например, у вас есть десять воркеров для обработки заказов. Каждый новый заказ попадает в очередь, и любой свободный воркер заберет его на обработку. Это гарантирует, что каждый заказ будет обработан только один раз.

Вторая модель — Publish-Subscribe, или топики (Topics). Здесь сообщение публикуется в топик и доставляется всем потребителям, которые на него подписаны. Классический пример — рассылка уведомлений. Событие "Вышел новый пост в блоге" публикуется в топик, и все подписанные сервисы (сервис рассылки на email, сервис push-уведомлений, сервис кэширования) получат его копию и выполнят свою работу.

Гарантии доставки

Одна из сильных сторон Artemis — богатый набор гарантий доставки, унаследованный от JMS.

• Auto Acknowledgement — это "отправил и забыл". Брокер считает сообщение доставленным сразу после отправки потребителю. Это быстро, но ненадежно.

• Client Acknowledgement — клиент должен явно отправить подтверждение (ack), что сообщение обработано. Это стандартный режим для надежной доставки.

• Transactional — подтверждение происходит в рамках транзакции, что позволяет объединить обработку нескольких сообщений или операций с БД в одну атомарную операцию.

• Durable Subscriptions — это особенность топиков. Если потребитель отключился, все сообщения, отправленные в топик, будут сохранены и доставлены ему, когда он вернется онлайн. Очень полезно для непостоянных подключений.

Техническая архитектура Artemis

Ядро

А теперь давайте заглянем под капот и поймем, откуда берется эта самая производительность.

Во-первых, фундамент всего — неблокирующий I/O. Вместо того чтобы создавать поток на каждое соединение, Artemis использует Netty. Это позволяет одному потоку обрабатывать тысячи одновременных подключений, что радикально снижает накладные расходы.

Во-вторых, это журналирующее хранилище. Когда сообщение должно быть сохранено на диск для надежности, Artemis не пишет его в случайное место. Он записывает его в конец последовательного журнала (append-only log). Последовательная запись на диск — это самая быстрая операция, что и дает высокую скорость работы с персистентностью.

В-третьих, это внутренний пул сообщений. Вместо постоянного создания и удаления объектов сообщений в памяти, Artemis использует их повторно, сводя к минимуму нагрузку на сборщик мусора в JVM.

[Клиенты (Producer/Consumer)]
        |
        | (Протоколы: Core, AMQP, MQTT...)
        |
[Протокольные модули (Protocol Handlers)]
        |
        | (Внутренняя модель сообщений)
        |
[Ядро Artemis (Non-blocking IO, Journal)]
        |
        | (Запись/Чтение)
        |
[Файлы журнала (Journal files on Disk)]

Схема

Давайте визуализируем это. Клиенты на разных протоколах подключаются к Artemis. На входе их встречают протокольные модули, которые трансформируют сообщение во внутренний формат брокера. Далее информация попадает в ядро, которое и принимает все ключевые решения: куда маршрутизировать, сохранять ли на диск. И если нужно сохранить, то оно отправляется в журнал на диске. Вся эта цепочка оптимизирована для максимальной скорости.

Кластеризация

Для отказоустойчивости и масштабирования Artemis можно объединять в кластеры. Есть два основных подхода.

Первый — Master-Slave репликация. Здесь есть ведущий (Master) и ведомый (Slave) сервер. В режиме Shared Store они используют общий диск, и при падении Master, Slave просто подхватывает его файлы и продолжает работу. В более современном режиме Replication Slave постоянно синхронно реплицирует журнал с Master по сети, что избавляет от необходимости в общем диске.

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

Apache Kafka: Краткое напоминание

Докладчик: Теперь давайте на время переключимся на второго игрока. Apache Kafka — это не просто брокер сообщений. Это распределенная платформа для потоковой обработки данных. Ее ключевые концепции немного другие.

• Данные организованы в топики.

• Каждый топик делится на партиции для горизонтального масштабирования. Партиции распределяются по разным серверам кластера.

• Каждое сообщение в партиции имеет свой уникальный офсет — последовательный номер.

• Потребители объединяются в Consumer Groups. Каждая партиция топика потребляется только одним потребителем из группы, что позволяет масштабировать обработку.

Важно понять философию: Kafka — это, в первую очередь, распределенный, надежный журнал событий (commit log).

Сравнение: Фундаментальная философия

И вот мы подходим к самому главному различию, которое определяет всё остальное. Это разница в фундаментальной философии.

ActiveMQ Artemis — это Умный брокер / Глупый клиент. Брокер — это мозг операции. Он знает, какие сообщения кому доставлены, управляет очередями, подписками, перенаправляет сообщения. Клиентам не нужно об этом заботиться, они просто подключаются и получают свои данные.

Apache Kafka — это Глупый брокер / Умный клиент. Брокер в Kafka очень простой. Он не знает, "кто что прочитал". Он просто хранит лог сообщений — упорядоченную последовательность. Всю логику выбора, что читать, несет на себе клиент. Он сам помнит свой офсет и сам решает, с какого места продолжить чтение. Это делает клиенты сложнее, а брокер — проще и легче масштабируемым.

Сравнительная таблица

Исходя из этой разной философии, вытекают все технические различия. Давайте пробежимся по таблице (см. Таблица 1).

• Основная модель: Artemis — брокер, Kafka — распределенный лог.

• Приоритет: Artemis оптимизирован для низкой задержки (доставить одно сообщение максимально быстро), а Kafka — для высокой пропускной способности (передать гигабайты данных в секунду).

• Семантика доставки: Artemis предлагает богатый набор из JMS (транзакции, ACK, TTL). У Kafka семантика проще, сфокусированная на потоковой обработке.

• Протоколы: Artemis — мультиязычный шлюз "из коробки". Kafka использует в основном свой собственный эффективный бинарный протокол.

• Хранение: В Artemis сообщение обычно удаляется после доставки и подтверждения. В Kafka сообщения хранятся долго — дни, недели, независимо от того, прочитали их или нет. Это позволяет "переигрывать" события.

• Масштабирование: Artemis масштабируется вертикально и через кластеризацию. Kafka масштабируется горизонтально линейно — добавил брокеров, увеличил количество партиций.

• Экосистема: Экосистема Kafka огромна — Kafka Connect для интеграции, Kafka Streams для обработки, Schema Registry. Artemis — это в первую очередь сам брокер.

Таблица 1. Сравнительная таблица: Artemis vs Kafka

Когда выбирать ActiveMQ Artemis?

Итак, исходя из этого, давайте сформулируем четкие рекомендации. Вам стоит выбрать ActiveMQ Artemis, если:

1. Вы делаете традиционную enterprise-интеграцию, где нужны строгие гарантии JMS, транзакции, TTL-сообщений.

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

3. В вашей системе есть разнородные клиенты — какие-то говорят по MQTT (датчики), какие-то по AMQP (сервисы), а какие-то по STOMP (веб-приложения). Artemis станет для них идеальным универсальным шлюзом.

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

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

Когда выбирать Apache Kafka?

Вам стоит выбрать Apache Kafka, если:

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

2. Вы используете Event Sourcing или вам необходимо долгосрочное хранение потока событий. Способность Kafka хранить историю — её киллер-фича.

3. Вы строите Data Pipeline для Big Data — вам нужно перекачивать гигантские объемы данных между системами, например, из логов приложений в Hadoop или Spark.

4. Вы строите архитектуру на основе событий (Event-Driven Architecture), где возможность отмотать время назад и воспроизвести все события с любого момента критически важна.

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

Нагрузочные различия

Теперь несколько слов о производительности под нагрузкой, потому что здесь тоже есть важные нюансы.

• Latency vs Throughput: Artemis — король низкой задержки. Он оптимизирован, чтобы доставить одно сообщение адресату максимально быстро. Kafka же оптимизирована для работы с пачками (batches). Из-за этого задержка на одно сообщение у Kafka может быть выше, но стоимость обработки одного сообщения в пачке из тысяч — ничтожна, что и дает феноменальную пропускную способность.

• Персистентность: И там, и там данные синхронно пишутся в журнал на диск для надежности. Но архитектура Kafka, заточенная под последовательную запись больших пачек, делает эту операцию чуть более эффективной на гигантских объемах.

• Масштабирование: Тут ключевое отличие. Artemis масштабируется в первую очередь вертикально (более мощный сервер) и за счет кластеров для отказоустойчивости. Kafka же изначально разработана для горизонтального масштабирования. Добавил новый брокер в кластер, увеличил количество партиций у топика — и пропускная способность линейно выросла.

Сводная таблица выбора

Давайте резюмируем выбор в этой простой и наглядной таблице (см. Таблица 2). Если вам нужно что-то из левой колонки — смотрите в сторону Artemis. Если из правой — ваш выбор Kafka.

Таблица 2. Сравнительная таблица выбора

В реальных системах нередко используется оба подхода одновременно. Kafka — в роли "долговременного журнала событий" и транспортного слоя для аналитики, а Artemis — как тактический брокер для процессинга транзакций в реальном времени. Такой гибридный паттерн можно встретить, например, у нас в Digital Q — платформе, которая сочетает BPM-оркестрацию, микросервисную генерацию и шину сообщений на Artemis. Это хороший пример, как не выбирать «или», а строить архитектуру под задачу.

Выводы

Докладчик: Итак, главный вывод, который я хочу, чтобы вы унесли с собой: Artemis и Kafka — это не прямые конкуренты. Они решают разные задачи и идеологически по-разному устроены.

• Artemis — это современный, сверхбыстрый классический брокер сообщений. Идеален для построения отзывчивых и надежных систем, где важна каждая миллисекунда и строгие гарантии доставки.

• Kafka — это мощная платформа для потоковых данных и событий. Идеальна для построения масштабируемых data pipelines и архитектур, где история и повторное воспроизведение событий важнее мгновенной доставки.

Критерий выбора — это всегда ваши конкретные требования: что важнее, latency или throughput, нужны ли вам транзакции JMS или возможность переиграть события за прошлую неделю.

Полезные ссылки

Всем, кто захочет поэкспериментировать, рекомендую начать с официальных сайтов:

• Официальный сайт ActiveMQ Artemis: https://activemq.apache.org/components/artemis/

• Официальный сайт Apache Kafka: https://kafka.apache.org/

• Экосистема low-code разработки микросервисных программных продуктов Digital Q: https://q.diasoft.ru/