RabbitMQ часто сравнивают с другим популярным брокером сообщений — Apache Kafka. Оба инструмента используются для обмена данными между приложениями, но реализуют принципиально разные модели доставки. RabbitMQ — push, когда сообщения отправляются получателям, а Kafka — pull, получатели сами достают сообщения из топика. 

В статье обсудим особенности каждого брокера, чтобы понять, под какие задачи лучше использовать RabbitMQ, а под какие — Kafka. Отдельно разберём, можно ли интегрировать эти системы управления очередями.

Принципы работы и сфера применения RabbitMQ

RabbitMQ — распределённый горизонтально масштабируемый брокер сообщений. Он передаёт сообщения между поставщиками и подписчиками через очереди. 

Принцип работы выглядит так:

  • RabbitMQ принимает сообщения от поставщиков, отправляет подтверждение о приёме и перенаправляет сообщение получателям.

  • Получатели подтверждают, что сообщение доставлено, или сигнализируют о неудачной доставке. Во втором случае сообщение остаётся в очереди до тех пор, пока не будет доставлено.

  • После доставки сообщение удаляется из системы. 

В очереди может храниться любой объём сообщений от неограниченного количества поставщиков, а получать их может неограниченное количество подписчиков. Фишка RabbitMQ как раз в гибкой маршрутизации — одно и то же сообщение могут получить сразу несколько подписчиков. Сначала оно попадёт на узел, а оттуда в очереди для всех подписчиков, которым должно быть доставлено. Благодаря такой особенности RabbitMQ подходит для нетривиальных бизнес-процессов и позволяет настраивать сложные системы с тысячами источников и приемников сообщений. 

Где может применяться: системы бронирования билетов, логистические программы.

Принципы работы и сфера применения Apache Kafka

Apache Kafka тоже считается распределённым брокером сообщений, но работает по другому принципу:

  • Kafka собирает у приложений данные и распределяет их по топикам в своём хранилище. 

  • Информацию из топиков читают другие программы и микросервисы.

  • В отличие от RabbitMQ, Kafka не отслеживает, получил ли подписчик сообщение, платформа просто хранит его в течение установленного промежутка времени. При этом она гарантирует, что сообщения находятся в той же последовательности, в которой поступили.

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

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

Где может применяться: системы аналитики, финансовые системы, социальные сети, онлайн-игры.

RabbitMQ или Kafka — что выбрать?

Выбор брокера сообщений, зависит от требований вашего проекта и конкретных задач. Разберём функциональные особенности RabbitMQ и Kafka, которые помогут принять решение.

Обработка сообщений

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

В RabbitMQ сообщение хранится до тех пор, пока принимающее приложение не получит его из очереди. Как только подписчик отмечает, что сообщение получено, оно удаляется. 

Протокол

RabbitMQ поддерживает несколько стандартизированных протоколов: AMQP, MQTT, STOMP и др. Это позволяет заменить его на любой брокер на основе AMQP.

Kafka использует пользовательский протокол поверх TCP/IP для связи между приложениями и кластером. Вы не сможете так просто удалить или заменить эту платформу, потому что она единственная реализует данный протокол. 

Работа с очередями

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

RabbitMQ поддерживает постановку сообщений в очередь через AMQP, например, для реализации рабочей очереди, которая доставляет сообщения циклически конкурирующим получателям. Kafka фокусируется на потоковой передаче событий и доставляет сообщения на основе порядка сообщений в разделе.

Потоковая передача данных

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

Масштабирование

Kafka подходит для горизонтального масштабирования путём добавления большего количества машин. RabbitMQ в основном предназначается для вертикального масштабирования путём увеличения мощности.

Маршрутизация

Главное преимущество RabbitMQ — гибкая маршрутизация. Сообщения маршрутизируются через обменник (exchange) перед попаданием в очереди. RabbitMQ предлагает несколько видов маршрутизации сообщений на стороне сервера (т.е. на стороне брокера) с помощью ключей, описанных в протоколе AMQP. 

У Kafka упрощённый подход к маршрутизации. Возможности, аналогичные RabbitMQ, она предоставляет через Kafka Connect и Kafka Streams. Эти компоненты выполняются на отдельном уровне и не являются функциями по умолчанию. 

Что есть у RabbitMQ и чего нет у Kafka

Масштабирование и поддержание порядка сообщений возможно с помощью каждого из брокеров сообщений. При этом у RabbitMQ есть одна интересная особенность, которой нет у Kafka: он позволяет подписчикам создавать произвольные группы событий.

Разберём на примере: разные приложения не могут совместно использовать очередь, потому что тогда они будут конкурировать за получение сообщений. Каждому из них нужна собственная очередь, которую они смогут настраивать так, как считают нужным. Это позволяет приложениям поддерживать порядок связанных событий. 

Промежуточные итоги

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

Используйте Kafka для:

  • хранения, чтения и повторного чтения потоковых данных;

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

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

Используйте RabbitMQ для:

  • длительных задач;

  • высокопроизводительных фоновых заданий;

  • интеграции между приложениями и внутри них. 

Можно ли использовать RabbitMQ и Kafka вместе

Хотя и RabbitMQ, и Kafka являются брокерами сообщений и решают схожие задачи, сегодня всё чаще встречаются команды, которые используют их на проектах параллельно. Дело в том, что у каждой технологии свои сильные стороны. У Kafka это масштабируемость, потоковая передача данных и возможность интеграции с другими технологиями. У RabbitMQ — надёжность и гибкость маршрутизации. Также параллельное использование RabbitMQ и Kafka уместно, если вы планируете перейти с одного брокера на другой. Это повышает безопасность миграции. 

Для тех, кто хочет погрузиться в тонкости работы RabbitMQ и разобраться, какое место он занимает в инфраструктуре

28 сентября у нас стартует курс по Rabbit MQ. На нём инфраструктурный инженер Алексей Барабанов расскажет, как не искать сложных решений там, где достаточно целевого хорошо настроенного инструмента. А ещё поделится кейсами и примерами из своего опыта.

Курс будет полезен тем, кто ещё не знаком с RabbitMQ, и тем, кто давно работает с ним только в базовом исполнении и хочет узнать о новых способах применения, нюансах отказоустойчивости и мониторинга.

Здесь можно ознакомиться с подробной программой и занять место: https://slurm.club/3STlApl

Комментарии (4)


  1. baldr
    12.10.2022 14:13
    +6

    Нет, ну правда - ну сколько уже можно? Сравнению только этих двух брокеров тут куча статей уже посвящена: раз, два, три, и просто поиск. ITSumma большой обзор на несколько статей сделала.

    И, внимание: в вашем же собственном блоге статьи про это же: раз, два, три.

    И, ведь, хоть бы что-то новое писали, но нет - перепечатывают одни и те же слова просто ради того чтобы рекламу куда-то впихнуть!


  1. Scratch
    12.10.2022 15:24
    +9

    RabbitMQ — распределённый горизонтально масштабируемый брокер сообщений

    RabbitMQ в основном предназначается для вертикального масштабирования путём увеличения мощности.

    Ок, спасибо, всё понятно. Надеюсь вы сам по этим статьям выбираете себе брокер


  1. MikeEshva
    12.10.2022 21:47
    +2

    Давно не видел столь технически безграмотных статей.

    Где может применяться: системы бронирования билетов, логистические программы.

    Серьёзно? Именно для этого? Почему именно эти предметные области понравились автору?

    Я бы сказал, что RabbitMQ подходит в случае, когда вам нужно иметь возможность маршрутизировать сообщения от "тупых" источников, состав которых может меняться с течением времени. В голову приходит какое-нибудь производственное предприятие, на котором есть куча датчиков и приложение мониторинга производственного процесса. Датчики выходят из строя, их заменяют, добавляют новые. Переписывать под каждое такое событие софт ни желания, ни возможности нет, но есть Кролик, в котором можно перенастроить таблицу маршрутизации.

    Вообще главная разница между этими брокерами заключается в концептуальном подходе: RabbitMQ — smart pipes dumb endpoints, Kafka — smart endpoints dumb pipes.

    Kafka собирает у приложений данные и распределяет их по топикам в своём хранилище.

    Kafka ничего у приложений не собирает. Producers сами пушат сообщения в топики. Producer должен заранее знать в какой топик он пушит.

    В отличие от RabbitMQ, Kafka не отслеживает, получил ли подписчик сообщение, платформа просто хранит его в течение установленного промежутка времени. При этом она гарантирует, что сообщения находятся в той же последовательности, в которой поступили.

    Kafka имеет группы подписчиков. В рамках группы Kafka отслеживает, получено ли сообщение или нет. Если да, перемещает указатель на следующее сообщение. Consumer должен явно сказать (на самом деле зависит от конфигурации), что он обработал сообщение.

    Retention policy Kafka может гибко настраиваться. Можно ничего не удалять, можно задать предельный размер данных, можно задать предельное время жизни сообщений.

    Подписчики сами отправляют Kafka запросы о новых сообщениях и указывают, что им нужно прочитать.

    В целом непонятное предложение. Во-первых, не подписчики, а потребители (consumers). Во-вторых, что и как они "указывают"? Может быть потребители должны знать из какого топика нужно читать эти сообщения?

    Основное назначение Apache Kafka — централизованный сбор, обработка, безопасное хранение и передача сообщений от разных сервисов.

    А разве то же самое нельзя сказать про любой другой брокер сообщений, в частности, Kafka?

    Обычно систему выбирают, когда нужно работать с большим количеством неструктурированных данных.

    Что это за неструктурированные данные такие? Запись лога? Да, бывают неструктурированные логи, но бывают и структурированные. JSON-объекты это структурированные данные? По-моему, да. Именно такие данные обычно передают в топиках Kafka.

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


    1. baldr
      12.10.2022 22:03

      Ну, еще можно вспомнить Rabbit Streams (тоже было на хабре) и сравнение будет уже не таким однозначным. RabbitMQ имеет еще довольно много плагинов - например MQTT.