Брокеры сообщений

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Всем

Брокеры сообщений

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

Одна программа отдаёт ему письмо (сообщение), брокер хранит его, а потом отдаёт другой программе, когда она будет готова.

Представим себе почтовое отделение:

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

Упрощённо, это как-то так:

# Программа А (производитель)
broker.send("order_queue", {"order_id": 123, "amount": 5000})

# Программа Б (потребитель)
message = broker.receive("order_queue")
process_order(message)

---

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

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

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

Брокер выступает в роли посредника, который принимает сообщения от «производителей» (producers) и передаёт их «потребителям» (consumers). Это позволяет организовать асинхронную связь между компонентами системы.

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

Среди брокеров различают RabbitMQ (модель очередей), Apache Kafka (модель топиков), ActiveMQ (классический брокер сообщений с поддержкой JMS), IBM MQ и Redis (который также используется для кэширования).

Потребители нуждаются в данных для выполнения своих функций - учёт, отслеживание, вычисления, мониторинг, проверки. Данные передаются как раз в виде структурированного пакета данных - сообщения. В RabbitMQ/IBM MQ/ActiveMQ их так и называют - «сообщения», а в Apache Kafla называются «топики».

---

Отличия между брокерами RabbitMQ и Kafka

Мы рассмотрим RabbitMQ и Kafka по отдельности. Для начала давайте разграничим их в виде таблицы отличий:

Критерий	RabbitMQ	Kafka
Архитектура	Основана на очередях (queues).	Основана на топиках (topics) с партициями (partitions).
Модель работы	Производитель → Обменник (Exchange) → Очередь → Потребитель.	Производитель → Топик → Партиция → Потребитель.
Упорядоченность	Гарантируется порядок в пределах одной очереди.	Гарантируется порядок только внутри одной партиции.
Состояние данных	Сообщения хранятся до доставки или истечения времени хранения.	Сообщения хранятся на диске в течение заданного времени (например, 7 дней).
Производительность	До десятков тысяч сообщений/секунду.	До миллионов сообщений/секунду.
Задержки	Низкие задержки благодаря прямой передаче через очереди.	Задержки выше из-за партиционирования и логической структуры.
Ресурсы	Требует меньше ресурсов для небольших нагрузок.	Требует больше памяти и дискового пространства.
Масштабируемость	Масштабируется за счёт добавления брокеров, но сложнее настроить кластер.	Легко масштабируется за счёт добавления брокеров и партиций.
Гарантия доставки	Гарантированная доставка каждого сообщения.	Доставка "хотя бы один раз" (at-least-once delivery).
Маршрутизация	Поддерживает сложные правила маршрутизации через обменники (exchanges).	Маршрутизация ограничена топиками и партициями.
Веб-интерфейс	Встроенный веб-интерфейс (RabbitMQ Management).	Нет встроенного интерфейса, но можно использовать сторонние инструменты.
Сценарии использования	Фоновые задачи, микросервисы, системы уведомлений.	Потоковая аналитика, логирование, мониторинг, IoT.
Примеры задач	Отправка email, обработка заказов, рассылка уведомлений.	Сбор и анализ логов, мониторинг событий, обработка данных в реальном времени.

---