Перейти к основному содержимому

Apache ActiveMQ против Kafka

· 7 мин. чтения

1. Обзор​

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

Таким образом, мы можем выбирать между несколькими продуктами. Apache Foundation предоставляет ActiveMQ и Kafka, которые мы сравним друг с другом в этой статье.

2. Общие факты​

2.1. Активный МК​

Active MQ — один из традиционных брокеров сообщений, целью которого является обеспечение безопасного и надежного обмена данными между приложениями. Он работает с небольшим объемом данных и поэтому специализируется на четко определенных форматах сообщений и обмене транзакционными сообщениями.

Следует отметить, что помимо этой «классической» есть еще одна версия: Active MQ Artemis. Этот брокер следующего поколения основан на HornetQ, код которого был предоставлен Apache Foundation компанией RedHat в 2015 году. На сайте Active MQ сказано, что:

Как только Artemis достигнет достаточного уровня функционального паритета с «классической» кодовой базой, она станет следующей основной версией ActiveMQ.

Итак, для сравнения нам нужно рассмотреть оба издания. Мы будем различать их, используя термины «Active MQ» и «Artemis» .

2.2. Кафка​

В отличие от Active MQ, Kafka — это распределенная система, предназначенная для обработки огромного количества данных. Мы можем использовать его для традиционного обмена сообщениями, а также:

  • отслеживание активности на сайте
  • показатели
  • агрегация журналов
  • потоковая обработка
  • поиск событий
  • журналы коммитов

Эти требования приобрели большое значение с появлением типичных облачных архитектур, построенных с использованием микросервисов.

2.3. Роль JMS и эволюция обмена сообщениями​

Служба сообщений Java (JMS) — это общий API для отправки и получения сообщений в приложениях Java EE. Это часть ранней эволюции систем обмена сообщениями, и она до сих пор является стандартом. В Jakarta EE он был принят как Jakarta Messaging . Итак, может быть полезно понять основные понятия:

  • нативный для Java, но независимый от поставщика API

  • необходимость в адаптере ресурсов JCA для реализации протокола связи конкретного поставщика

  • модели назначения сообщений:

  • Очереди ( P2P ) для обеспечения упорядочения сообщений и однократной обработки сообщений даже в случае нескольких потребителей.

  • Темы ( PubSub ) как реализация шаблона публикации-подписки, что означает, что несколько потребителей будут получать сообщения в течение срока их подписки на тему.

  • форматы сообщений:

  • Заголовки как стандартизированная метаинформация, с которой работает брокер (например, приоритет или дата истечения срока действия).

  • Свойства как нестандартизированная метаинформация, которую потребитель может использовать для обработки сообщений.

  • Тело , содержащее полезную нагрузку — JMS объявляет пять типов сообщений, но это актуально только для использования API, а не для этого сравнения

Однако эволюция шла в открытом и независимом направлении — независимо от платформы потребителя и производителя и независимо от поставщиков брокеров обмена сообщениями. Существуют протоколы, определяющие собственные модели назначения:

  • AMQP — бинарный протокол для независимого от поставщика обмена сообщениями — использует общие узлы.
  • MQTT — облегченный бинарный протокол для встраиваемых систем и IoT — использует темы
  • STOMP — простой текстовый протокол, который позволяет обмениваться сообщениями даже из браузера — использует общие места назначения .

Еще одна разработка — добавление ранее надежной передачи отдельных сообщений («традиционный обмен сообщениями») к обработке больших объемов данных по принципу «Выстрелил и забыл» за счет распространения облачных архитектур. Можно сказать, что сравнение Active MQ и Kafka — это сравнение образцовых представителей этих двух подходов. Например, альтернативой Kafka может быть NATS .

3. Сравнение​

В этом разделе мы сравним наиболее интересные особенности архитектуры и разработки между Active MQ и Kafka.

3.1. Модели назначения сообщений, протоколы и API​

Active MQ полностью реализует модель назначения сообщений JMS для очередей и тем и сопоставляет с ними сообщения AMQP, MQTT и STOMP. Например, сообщение STOMP сопоставляется с сообщением JMS BytesMessage в Topic . Кроме того, он поддерживает OpenWire , что обеспечивает межъязыковой доступ к Active MQ.

Artemis определяет свою собственную модель назначения сообщений независимо от стандартных API и протоколов, а также должна сопоставлять их с этой моделью:

  • Сообщения отправляются на адрес , которому присваивается уникальное имя, тип маршрутизации и ноль или более очередей .

  • Тип маршрутизации определяет, как сообщения направляются с адреса в очереди, связанные с этим адресом. Определены два типа:

  • ANYCAST : сообщения направляются в одну очередь по адресу

  • MULTICAST : сообщения направляются в каждую очередь по адресу

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

  • Одно сообщение распределяется в один раздел.
  • Упорядочивание обеспечивается только для сообщений в пределах одного раздела.
  • По умолчанию последующие сообщения распределяются циклически по разделам темы.
  • Если мы используем ключи сообщений, то сообщения с одним и тем же ключом попадут в один и тот же раздел.

У Kafka есть свои API . Хотя для JMS также существует адаптер ресурсов , мы должны знать, что концепции не полностью совместимы. AMQP, MQTT и STOMP официально не поддерживаются, но есть коннекторы для AMQP и MQTT .

3.2. Формат сообщения и обработка​

Active MQ поддерживает стандартный формат сообщений JMS, состоящий из заголовков, свойств и тела (как описано выше). Брокер должен поддерживать состояние доставки каждого сообщения, что снижает пропускную способность. Поскольку это поддерживается JMS, потребители могут синхронно извлекать сообщения из пункта назначения, или сообщения могут быть асинхронно отправлены брокером.

Kafka не определяет какой-либо формат сообщения — это полностью ответственность производителя. Для каждого сообщения нет состояния доставки, только смещение для каждого потребителя и раздела. Смещение — это индекс последнего доставленного сообщения. Это не только быстрее, но и позволяет повторно отправлять сообщения путем сброса смещения без запроса производителя.

3.3. Интеграция Spring и CDI​

JMS — это стандарт Java/Jakarta EE, поэтому он полностью интегрирован в приложения Java/Jakarta EE. Таким образом, соединения с Active MQ и Artemis легко управляются сервером приложений. С Artemis мы даже можем использовать встроенного брокера . Для Kafka управляемые подключения доступны только при использовании адаптера ресурсов для JMS или Eclipse MicroProfile Reactive .

Spring имеет интеграцию с JMS , а также с AMQP , MQTT и STOMP . Кафка также поддерживается. С Spring Boot мы можем использовать встроенные брокеры для Active MQ , Artemis и Kafka .

4. Варианты использования Active MQ/Artemis и Kafka​

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

4.1. Варианты использования Active MQ/Artemis​

  • Обрабатывать только небольшое количество сообщений в день
  • Высокий уровень надежности и транзакционности
  • Преобразование данных на лету, задания ETL

4.2. Варианты использования Кафки​

  • Обработка больших объемов данных

  • Обработка данных в режиме реального времени

  • Отслеживание активности приложений

  • Ведение журнала и мониторинг

  • Доставка сообщений без преобразования данных (было бы возможно, но не просто)

  • Доставка сообщений без транспортных гарантий (было бы возможно, но не просто)

5. Вывод​

Как мы видели, и у Active MQ/Artemis, и у Kafka есть свои цели и, следовательно, свои оправдания. Важно знать их различия, чтобы выбрать правильный продукт для правильного случая. Следующая таблица еще раз кратко поясняет эти различия:

Различия между Active MQ и Kafka 

       | Критерии    | Актив MQ Классический    | Активный MQ Артемида    | Кафка   | 
      | Сценарии использования    | Традиционный обмен сообщениями (надежный, транзакционный)    | Распределенная потоковая передача событий   | 
  | Обмен сообщениями P2P    | Очереди    | Адрес с типом маршрутизации ANYCAST    | –   | 
  | Сообщения PubSub    | Темы    | Адрес с типом маршрутизации MULTICAST    | Темы   | 
  | API/протоколы    | JMS, АМКП.  MQTT, STOMP, OpenWire    | Клиенты Kafka, коннекторы для AMQP и MQTT, адаптер ресурсов JMS   | 
  | Пулл- и пуш-обмен сообщениями    | Push на основе    | Вытягивающий   | 
  | Ответственность за доставку сообщений    | Производитель должен гарантировать, что сообщение будет доставлено    | Потребитель потребляет сообщения, которые он должен потреблять   | 
  | Поддержка сделки    | JMS, штат Калифорния    | [Диспетчер пользовательских транзакций](/lessons/b/-kafka-exactly-once)   | 
  | Масштабируемость    | [Сети брокеров](https://activemq.apache.org/networks-of-brokers.html)    | [Кластеры](https://activemq.apache.org/components/artemis/documentation/1.0.0/clusters.html)    | высокая масштабируемость (разделы и реплики)   | 
  | Чем больше потребителей…    | … чем медленнее производительность    | … не тормозит   |