RabbitMQ — программный брокер сообщений на основе стандарта AMQP — тиражируемое

связующее программное обеспечение, ориентированное на обработку сообщений [1].

RabbitMQ довольно часто применяется в различных Big Data проектах.

RabbitMQ поддерживает несколько языков программирования (Perl, Python, Ruby, PHP), а также
обеспечивает горизонтальное масштабирование для построения кластерных решений [1].

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

аналогичного назначения. Используется в высоконагруженных Big Data проектах [2].

RabbitMQ, в связи с некоторыми его технологическими особенностями реализации, не является

полноценной заменой Apache Kafka [2].

В упрощенном виде управление сообщениями выполняется в RabbitMQ следующим образом [2]:

1. отправители (publishers) отправляют сообщения на обменники (exchange);
2. обменники отправляют сообщения в очереди и в другие обменники;
3. при получении сообщения RabbitMQ отправляет подтверждения отправителям;
4. получатели (consumers) поддерживают постоянные TCP-соединения с RabbitMQ и
объявляют, какую очередь они получают;
5. RabbitMQ проталкивает (push) сообщения получателям;
6. получатели отправляют подтверждения успеха или ошибки получения сообщения;
7. после успешного получения сообщение удаляется из очереди.

Сходства RabbitMQ и Kafkaх [2]

RabbitMQ Apache Kafka

Основная идея (концепция)

Модель проталкивания (push). Отправляет Модель вытягивания (pull). Получатели

необходимые сообщения получателям. (consumers) достают из топика (topic) нужные
им сообщения.

Основные отличия
 Сохранение сообщений

Помещает сообщение в очередь FIFO (First Добавляет сообщение в журнал (записывает

Input – First Output) и отслеживает статус на диск), предоставляя получателю самому
этого сообщения в очереди. RabbitMQ заботиться о получении нужной
удаляет сообщение после доставки его информации из топика.
получателю. Хранит сообщение до момента
запланированной очистки журнала. Таким
образом, сохраняет текущее и все прежние
состояния системы - может использоваться
в качестве достоверного источника
исторических данных.

Балансировка

Благодаря pull-модели доставки сообщений Балансировка нагрузки выполняется

RabbitMQ сокращает время задержки, автоматически путем перераспределения
однако возможно переполнение получателей по разделам (partition) топика.
получателей, если сообщения прибудут в
очередь быстрее, чем те могут их обработать.
Поскольку каждый получатель
запрашивает/выгружает разное количество
сообщений, то распределение работы может
стать неравномерным, что повлечет
задержки и потерю порядка сообщений во
время обработки.
Для предупреждения этого каждый
получатель настраивает предел
предварительной выборки (QoS) –
ограничение на количество скопившихся
неподтвержденных сообщений.

Пропускная способность

Гарантирует порядок сообщений в разделе

топика (partition) без конкурирующих
получателей, что позволяет объединять
сообщения в пакеты для более эффективной
доставки и повышает пропускную
способность системы.

Масштабируемость

Считается более адаптивной к

масштабированию, обеспечивая
ежедневный обмен миллиардами
сообщений.
Стоит отметить, что далеко не каждый Big
Data проект нуждается в таких высоких
цифрах.
 Маршрутизация

4 способа маршрутизации на разные Реализует лишь 1 способ записи сообщений

обменники (exchange) для постановки в на диск, без маршрутизации.
различные очереди. Это позволяет
использовать мощный и гибкий набор
шаблонов обменов сообщениями.

Упорядочивание сообщений

Позволяет поддерживать относительный Обеспечивает простой способ поддержания

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

Работа с клиентом

«Умный сервер, тупой клиент», поскольку «Тупой сервер, умный клиент», что
брокер сам обеспечивает всю логику означает необходимость реализации логики
работы с сообщениями. работы с сообщениями на клиентской
стороне, т.е consumer заботится о
получении нужных сообщений

Сходства

Схема обмена сообщениями

Работает по схеме «издатель-подписчик» (publisher-consumer, отправитель-получатель),

когда источники данных направляют потоки информации, а получатели обрабатывают их по
мере потребности.

Потоки и пакеты сообщений

Оба брокера позиционируются для работы с непрерывными потоками информации.

Однако, они позволяют объединять сообщения в пакеты.

Пакетирование является скорее «мнимым» Пакетирует более явно, повышая

из-за пассивной модели приёма, не эффективность от него благодаря своим
препятствующей конфликтам получателей. возможностям по распределению пакетов.

Уведомления о сообщениях

Уведомления о сообщениях — оба брокера обмениваются сигналами с отправителями и

получателями при отправке и получении сообщений.

Стратегии доставки

Оба брокера способны реализовать стратегии «как максимум однократная доставка» и

«как минимум однократная доставка», что позволяет сократить риски потери или
дублирования сообщений.
 Репликация

Оба брокера обеспечивают репликацию сообщений.

Гарантии отправки

Оба брокера гарантируют порядок отправки сообщений с помощью уведомлений и

стратегий доставки.

Плюсы

● Гибкое управление очередями

сообщений (маршрутизация, шаблоны
доставки, мониторинг получения)

Минусы

Повышенное потребление ресурсов ->

снижение производительности в условиях
увеличенных нагрузок

Что выбирать для Big Data проекта [2]

Поскольку именно такой режим работы характерен для Big Data систем, то в большинстве
случаев Kafka является наилучшим средством для управления сообщениями.
Например, в случае сбора и агрегации множества событий от IoT-устройств, клиентских
метрик, лог-файлов и аналитики Big Data с перспективой увеличения источников информации
понадобится Kafka. А если необходим быстрый сообщениями между несколькими сервисами,
RabbitMQ отлично справится с этой задачей [5]. RabbitMQ можно использовать для обработки
событий в режиме реального времени, т.е. этот брокер — решение только для реагирования
на события, которые происходят сейчас. Kafka, напротив, обеспечивает полную историческую
достоверность и сохранность всех данных, а также упрощает их распространение. Исходные
данные принадлежат только отправителю, но каждый получатель может их фильтровать,
трансформировать, дополнять данными из других источников и сохранять в собственных
базах данных [6].

Подводя итог сравнению Kafka и RabbitMQ, можно сделать вывод, что выбор того или иного
брокера в первую очередь зависит от нагрузки, в которой предполагается его использование. В
случае адекватного применения каждая из этих систем обмена сообщениями будет
эффективным инструментом реализации Big Data проекта.
 Краткое сравнение Kafka и Rabbit MQ [2]

Список литературы:
1. Одноимённая статья в википедии
2. Apache Kafka vs RabbitMQ в Big Data
3. What is RabbitMQ?