Если вам потребуется организовать обмен данными между системами, какой выбор вы сделаете, если вас разбудят среди ночи? Давайте разберёмся, как происходит обмен информацией и какую роль в этом играют брокеры.

Виды общения

Общение — это основа взаимодействия между людьми и системами. Самый привычный формат — диалог, когда один человек (N) передаёт информацию другому (Y) и ожидает ответ. Это классическая модель запроса и ответа.

Но бывают ситуации, когда N транслирует сообщение Y, не ожидая ответа. Например, рекламные рассылки или push-уведомления.

Существует также обмен через посредника. Представим, что N передаёт сообщение X, а тот, в свою очередь, распространяет его среди друзей C, D и E. Этот принцип реализован в мессенджерах и новостных рассылках.

Другой вариант — N записывает сообщение и оставляет его в специальном ящике. X может забрать его в удобное время. Здесь каждый получатель получает только одно сообщение.

Паттерны обмена информацией

В программировании сервисы и приложения взаимодействуют между собой, обмениваясь данными. Основные модели взаимодействия:

• Request-Response (Запрос-Ответ) – примером является работа HTTP, когда клиент делает запрос на сервер и ждёт ответа.
• One-Way (Односторонний обмен) или Fire and Forget (Отправил и забыл) – отправитель передаёт сообщение без ожидания ответа, как в случае с UDP-пакетами.
• Publish-Subscribe (Публикация-Подписка, Pub-Sub) – отправитель публикует сообщение в канал, а подписчики его получают.
• Point-to-Point (Точка-Точка) – каждое сообщение доставляется только одному получателю.

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

Роль брокеров сообщений

Брокер сообщений – это программный посредник, который реализует паттерны Pub-Sub и Point-to-Point. Его основная задача – упрощение маршрутизации, хранения и доставки сообщений. Использование брокера оправдано, если:

• задачи требуют значительных ресурсов;
• не нужен мгновенный ответ;
• необходимо координировать множество сервисов;
• требуется масштабируемость и отказоустойчивость.

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

При передаче данных возможны сбои, поэтому брокеры предлагают различные уровни гарантии доставки:

• At most once (Не более одного раза) – сообщения могут теряться.
• At least once (Хотя бы один раз) – возможна повторная отправка, чтобы гарантировать доставку.
• Exactly once (Строго один раз) – сообщения не теряются и не дублируются.

Очереди и топики

Брокеры реализуют два основных механизма работы:

• Очереди (Queue, Point-to-Point) – сообщение читается одним получателем и затем удаляется.
• Топики (Topic, Pub-Sub) – сообщение доставляется сразу нескольким подписчикам.

Популярные брокеры сообщений

Среди множества решений можно выделить наиболее популярные:

• RabbitMQ
• Apache Kafka
• Datareon
• Redis Streams
• Amazon SQS

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

Альтернативные подходы

Вместо брокера можно использовать SQL-базу данных как очередь сообщений, но это менее гибкий вариант.

RabbitMQ: «умный брокер, тупой потребитель»

RabbitMQ – традиционный брокер с поддержкой Pub-Sub и Point-to-Point. Он активно управляет сообщениями: распределяет их по подписчикам, отслеживает их статус и удаляет после обработки. Он поддерживает At most once и At least once, а его настройка проще, чем у Kafka.

Принцип работы RabbitMQ:

1. Отправитель (Publisher) передаёт сообщение в обменник (Exchange).
2. Сообщение попадает в одну или несколько очередей (Queue).
3. Подписчики (Consumers) забирают сообщения из очереди.

Apache Kafka: «тупой брокер, умный потребитель»

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

Принцип работы Kafka:

1. Продюсер (Producer) отправляет сообщение в топик.
2. Брокер записывает сообщение в журнал (лог) без удаления.
3. Подписчики (Consumers) сами запрашивают (pull) сообщения.

Kafka vs RabbitMQ: что выбрать?

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

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