8.05. Брокеры сообщений
Брокеры сообщений
Что такое брокер сообщений?
Брокер сообщений — это программное обеспечение или система, которая управляет обменом данными между приложениями, сервисами или системами.
Брокер выступает в роли посредника, который принимает сообщения от «производителей» (producers) и передаёт их «потребителям» (consumers). Это позволяет организовать асинхронную связь между компонентами системы.
Производитель отправляет сообщение в брокер и продолжает свою работу, не дожидаясь ответа от потребителя, а брокер гарантирует доставку сообщений даже в случае сбоев (например, через очереди и подтверждения) и позволяет распределять нагрузку между несколькими потребителями, что упрощает масштабирование.
Среди брокеров различают:
- RabbitMQ (модель очередей),
- Apache Kafka (модель топиков),
- ActiveMQ (классический брокер сообщений с поддержкой JMS),
- IBM MQ,
- Redis (который также используется для кэширования).
Функциональное назначение
Декуплинг компонентов
- Производитель и потребитель не зависят друг от друга во времени, пространстве и скорости обработки.
- Изменение одного компонента не требует модификации других при соблюдении контракта сообщения.
Буферизация нагрузки
- Поглощение пиковых нагрузок за счёт временного хранения сообщений.
- Предотвращение перегрузки потребителей при всплесках активности производителей.
Маршрутизация и фильтрация
- Направление сообщений по правилам: по ключу, содержимому, заголовкам.
- Трансформация формата сообщений между системами с разными требованиями.
Гарантии доставки
- Обеспечение надёжной передачи при сетевых сбоях и перезапусках компонентов.
- Управление семантикой доставки в зависимости от требований бизнес-логики.
Архитектурные модели
Точечная очередь (Point-to-Point)
Производитель → [Очередь] → Потребитель
- Каждое сообщение доставляется ровно одному потребителю.
- Потребители конкурируют за сообщения в рамках группы.
- Применение: фоновые задачи, обработка заказов, импорт данных.
Публикация-подписка (Publish-Subscribe)
Производитель → [Топик] → Подписчик 1
→ Подписчик 2
→ Подписчик 3
- Каждое сообщение доставляется всем активным подписчикам.
- Подписчики независимы: обработка одним не влияет на других.
- Применение: рассылка уведомлений, события домена, кэш-инвалидация.
Гибридные модели
- Виртуальные очереди поверх топиков: каждый потребитель получает копию потока, но обрабатывает сообщения конкурентно внутри группы.
- Маршрутизация по шаблону: подписка на подмножество событий через фильтрацию (например, по заголовкам или пути в иерархии топиков).
Ключевые концепции
Сообщение (Message)
- Единица передаваемых данных с метаданными.
- Структура: идентификатор, заголовки (метаданные), тело (полезная нагрузка), временная метка.
- Идемпотентность: сообщения должны допускать повторную обработку без побочных эффектов.
Очередь (Queue)
- Буфер хранения сообщений с семантикой FIFO (first-in-first-out).
- Гарантия упорядоченности в пределах одной очереди.
- Блокировка сообщения во время обработки для предотвращения параллельной обработки.
Топик (Topic)
- Логический канал публикации событий.
- Не хранит состояние потребителей — каждый подписчик отслеживает свою позицию.
- Поддержка иерархии (например,
orders.us.eastс возможностью подписки наorders.*).
Производитель (Producer)
- Компонент, отправляющий сообщения в брокер.
- Не зависит от доступности или количества потребителей.
- Может указывать ключ маршрутизации для определения партиции или очереди назначения.
Потребитель (Consumer)
- Компонент, извлекающий сообщения из брокера.
- Подтверждает обработку (acknowledgement) для удаления сообщения из очереди.
- Может принадлежать к группе потребителей для распределения нагрузки.
Механизмы надёжности
Подтверждение доставки (Acknowledgement)
- Автоматическое: брокер считает сообщение обработанным после передачи потребителю.
- Ручное: потребитель явно подтверждает успешную обработку после завершения бизнес-логики.
- Повторная доставка: сообщения без подтверждения возвращаются в очередь после таймаута или при отказе потребителя.
Персистентность
- Запись сообщений на диск до подтверждения производителю.
- Защита от потери данных при перезапуске брокера.
- Торговля между производительностью (память) и надёжностью (диск).
Дедупликация
- Фильтрация дубликатов на основе идентификатора сообщения.
- Требует хранения истории обработанных идентификаторов в течение заданного окна.
- Критична для сценариев с семантикой «ровно один раз».
Семантика доставки
| Семантика | Гарантии | Требования | Применение |
|---|---|---|---|
| At-most-once | Сообщение может быть потеряно, но не будет обработано дважды | Минимальные накладные расходы | Некритичные данные: телеметрия, логи |
| At-least-once | Сообщение гарантированно доставлено, но возможна дубликация | Подтверждение после обработки | Финансовые операции, заказы |
| Exactly-once | Сообщение обработано ровно один раз | Транзакционность + дедупликация | Платежи, бухгалтерия |
Типы архитектур брокеров
| Тип | Характеристики | Сценарии |
|---|---|---|
| Очереди с удалением | Сообщение удаляется после подтверждения; краткосрочное хранение | Обработка задач, фоновые джобы |
| Журналы (logs) | Неизменяемая последовательность; длительное хранение; повторное чтение | Аудит, событийное хранение, потоковая аналитика |
| Гибридные | Комбинация очередей и журналов; гибкая политика хранения | Микросервисы с разными требованиями к данным |
Сравнение с альтернативными подходами
| Подход | Декуплинг | Надёжность | Сложность | Задержка |
|---|---|---|---|---|
| Прямые вызовы (HTTP/RPC) | Нет | Низкая (зависит от сети) | Низкая | Низкая |
| Очереди сообщений | Высокий | Высокая | Средняя | Умеренная |
| Журналы событий | Максимальный | Очень высокая | Высокая | Низкая (потоковая) |
| База данных как очередь | Средний | Средняя | Низкая | Высокая |
Мы рассмотрим RabbitMQ и Kafka по отдельности. Для начала давайте разграничим
| Критерий | RabbitMQ | Kafka |
|---|---|---|
| Архитектура | Основана на очередях (queues) | Основана на топиках (topics) с партициями (partitions) |
| Модель работы | Производитель → Обменник (Exchange) → Очередь → Потребитель | Производитель → Топик → Партиция → Потребитель |
| Упорядоченность | Гарантируется порядок в пределах одной очереди | Гарантируется порядок только внутри одной партиции |
| Состояние данных | Сообщения хранятся до доставки или истечения времени хранения | Сообщения хранятся на диске в течение заданного времени (например, 7 дней) |
| Производительность | До десятков тысяч сообщений в секунду | До миллионов сообщений в секунду |
| Задержки | Низкие задержки благодаря прямой передаче через очереди | Задержки выше из-за партиционирования и логической структуры |
| Ресурсы | Требует меньше ресурсов для небольших нагрузок | Требует больше памяти и дискового пространства |
| Масштабируемость | Масштабируется за счёт добавления брокеров, но кластеризация сложнее в настройке | Легко масштабируется за счёт добавления брокеров и партиций |
| Гарантия доставки | Гарантированная доставка каждого сообщения | Доставка "хотя бы один раз" (at-least-once delivery) |
| Маршрутизация | Поддерживает сложные правила маршрутизации через обменники (exchanges) | Маршрутизация ограничена топиками и партициями |
| Веб-интерфейс | Встроенный веб-интерфейс (RabbitMQ Management) | Отсутствует встроенное решение; используются сторонние инструменты |
| Сценарии использования | Фоновые задачи, микросервисы, системы уведомлений | Потоковая аналитика, логирование, мониторинг, IoT |
| Примеры задач | Отправка email, обработка заказов, рассылка уведомлений | Сбор и анализ логов, мониторинг событий, обработка данных в реальном времени |
Сценарии применения
Асинхронная обработка
- Отправка электронной почты после регистрации без блокировки основного потока.
- Генерация отчётов в фоновом режиме.
Согласование распределённых транзакций
- Сага-паттерн: компенсирующие операции при частичном сбое.
- Событийная архитектура для поддержания согласованности между контекстами.
Буферизация между системами
- Сглаживание различий в скорости обработки между высоконагруженным фронтендом и медленным бэкендом.
- Интеграция систем с разной доступностью.
Широковещательные уведомления
- Рассылка изменений конфигурации всем экземплярам сервиса.
- Инвалидация кэша при изменении данных.