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

Введение: Почтальон для программ

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

Брокер сообщений (Message Broker) — это “почта” для программ. Программа-отправитель не вызывает программу-получателя напрямую. Она отправляет сообщение брокеру. Брокер хранит сообщение и доставляет его получателю, когда тот готов.

Брокер решает классические проблемы интеграции систем: как быть, если получатель временно недоступен? Как доставить сообщение нескольким получателям? Как гарантировать, что сообщение не потеряется? Как сделать так, чтобы отправитель и получатель не зависели друг от друга?

Для системного аналитика брокер сообщений — это архитектурный паттерн для асинхронной, слабосвязанной, надёжной интеграции. Это фундамент для событийно-ориентированных систем, микросервисов, ETL-процессов, очередей задач.

Зачем нужен брокер сообщений

Проблемы прямого взаимодействия

Основные понятия

Сообщение (Message)

Блок данных, который передаётся от отправителя к получателю.

Сообщение:
  заголовки:
    message_id: "abc-123"
    timestamp: "2024-01-15T10:30:00Z"
    correlation_id: "req-789"
    content_type: "application/json"
  тело:
    order_id: 1001
    amount: 5000

Очередь (Queue)

Хранилище сообщений в порядке поступления (FIFO). Сообщение достаётся одному получателю.

    graph LR
    A[Отправитель] -->|сообщение| Q[Очередь]
    Q -->|сообщение| B[Получатель 1]
    Q -->|сообщение| C[Получатель 2]
  

Топик (Topic)

Канал, на который можно подписаться. Сообщение доставляется всем подписчикам.

    graph LR
    A[Отправитель] -->|сообщение| T[Топик]
    T -->|сообщение| B[Подписчик 1]
    T -->|сообщение| C[Подписчик 2]
    T -->|сообщение| D[Подписчик 3]
  

Брокер (Broker)

Сервер, который принимает, хранит, маршрутизирует и доставляет сообщения.

Синхронность и асинхронность

Аналогия: Синхронный вызов — это телефонный звонок (должны оба быть на линии). Асинхронный — это отправка письма (можно отправить в любое время).

Зачем нужна асинхронность

Сглаживание пиков (Load levelling)

    graph LR
    A[Пиковая нагрузка<br>1000 сообщений/с] --> Q[Очередь]
    Q --> B[Стабильная нагрузка<br>100 сообщений/с]
  

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

Разделение отправителя и получателя (Decoupling)

• Отправитель не знает IP, порт, протокол получателя
• Отправитель не знает, сколько получателей
• Отправитель не знает, доступен ли получатель
• Получатель может быть переписан без изменения отправителя

Буферизация

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

Надёжность

Персистентность (Persistent)

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

Подтверждения (Acknowledgment)

    sequenceDiagram
    participant A as Отправитель
    participant B as Брокер
    participant C as Получатель
    
    A->>B: Сообщение
    B-->>A: ACK (я получил)
    B->>C: Сообщение
    C-->>B: ACK (я обработал)
    B-->>B: Удалить сообщение
  

Что даёт: Сообщение не потеряется, если получатель упал до обработки.

Dead Letter Queue (DLQ)

Очередь для сообщений, которые не удалось обработать после нескольких попыток.

    graph LR
    A[Основная очередь] -->|ошибка| B[DLQ]
    B -->|анализ| C[Администратор]
  

Популярные брокеры

Какие задачи решает брокер

Разгрузка сервера (Offloading)

Тяжёлая обработка выносится в фоновые задачи.

    graph LR
    A[Веб-сервер] -->|быстро| Q[Очередь]
    Q -->|медленно| B[Воркер]
  

Веб-сервер быстро отвечает клиенту, а тяжёлая обработка идёт в фоне.

Распределение работы (Load balancing)

Несколько воркеров читают из одной очереди.

    graph LR
    Q[Очередь] --> W1[Воркер 1]
    Q --> W2[Воркер 2]
    Q --> W3[Воркер 3]
  

Уведомление многих (Broadcast)

Одно событие — много подписчиков.

    graph LR
    A[Событие] --> T[Топик]
    T --> B[CRM]
    T --> C[Биллинг]
    T --> D[Логирование]
  

Интеграция разнородных систем

Разные протоколы, разные форматы.

    graph LR
    A[Старая система<br>SOAP] --> B[Брокер]
    C[Новая система<br>REST] --> B
    B --> D[Склад<br>JMS]
    B --> E[Биллинг<br>HTTP]
  

Брокер как хранилище

Некоторые брокеры (Kafka) хранят сообщения определённое время. Это позволяет:

• Новому сервису прочитать историю событий (replay)
• Перечитать сообщение, если обработка упала
• Анализировать поток событий

    graph LR
    A[Событие] --> K[Kafka<br>хранение 7 дней]
    K --> B[Сервис 1]
    K --> C[Сервис 2]
    C -.->|запрос истории| K
  

Брокер и микросервисы

В микросервисной архитектуре брокер часто используется для:

• Коммуникации между сервисами (асинхронно)
• Событийной архитектуры (сервисы реагируют на события)
• Согласованности данных (обновление нескольких сервисов через события)
• CQRS (команды и события)

    graph TD
    A[Сервис заказов] -->|событие - заказ создан| B[Kafka]
    B -->|заказ создан| C[Сервис платежей]
    B -->|заказ создан| D[Сервис склада]
    B -->|заказ создан| E[Сервис уведомлений]
  

Распространённые ошибки

Ошибка 1: Использование брокера для синхронных вызовов

Пытаются получить ответ в той же транзакции через брокер (request-response через очереди). Это сложно и не нужно.

Решение: Для синхронных вызовов используйте HTTP/gRPC.

Ошибка 2: Игнорирование идемпотентности

Брокер может доставить сообщение дважды (at-least-once). Получатель не обрабатывает дубликаты.

Решение: Сделать обработку идемпотентной (по idempotency key).

Ошибка 3: Нет мониторинга очередей

Очередь растёт, никто не знает, почему.

Решение: Мониторинг глубины очереди, алерты при превышении порога.

Ошибка 4: Неправильный выбор брокера

Выбрали Kafka для сложной маршрутизации (нужен RabbitMQ). Или RabbitMQ для высокой нагрузки (нужна Kafka).

Решение: Изучить сильные стороны брокеров.

Ошибка 5: Отсутствие DLQ

Сообщения-ошибки теряются или зависают в очереди.

Решение: Настроить Dead Letter Queue.

Резюме

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

2. Ключевые понятия: сообщение, очередь (одному получателю), топик (многим получателям), брокер (сервер).

3. Асинхронность: отправитель не ждёт ответа. Брокер накапливает сообщения, если получатель недоступен.

4. Что даёт брокер: разгрузка сервера, распределение работы, уведомление многих, интеграция разнородных систем, сглаживание пиков.

5. Надёжность: персистентность (на диск), подтверждения (ACK), Dead Letter Queue (DLQ).

6. Когда нужен брокер: асинхронные задачи, событийная архитектура, интеграция систем, очереди задач.