Skip to main content

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

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

Разные брокеры используют разные протоколы. Они могут быть как собственными (проприетарными), так и общепринятыми. Как правило, эти протоколы работают поверх TCP (хотя в некоторых случаях их могут заворачивать в WebSocket).

Типичные протоколы брокеров сообщений

AMQP

AMQP (Advanced Message Queuing Protocol) — один из самых распространённых протоколов для брокеров. Используется RabbitMQ, ActiveMQ и другими брокерами.

  • Работает поверх TCP.
  • Поддерживает различные модели обмена: очереди, топики, exchanges.
  • Гарантирует доставку сообщений (persistent mode).
  • Широко используется в корпоративных интеграциях.

MQTT

MQTT (Message Queuing Telemetry Transport) — лёгкий протокол, часто применяемый в IoT (Internet of Things).

  • Минимальный размер заголовков (от 2 байт).
  • Работает поверх TCP.
  • Поддерживает три уровня QoS (Quality of Service) — от «не гарантируется» до «гарантированная доставка».
  • Идеален для встраиваемых устройств и сценариев с низкой пропускной способностью.

STOMP

STOMP (Simple Text Oriented Messaging Protocol) — текстовый протокол, также используемый с брокерами.

  • Текстовый (читаемый человеком), похож на HTTP.
  • Работает поверх TCP (иногда WebSocket).
  • Простой в реализации и отладке.

Kafka Protocol

Apache Kafka использует собственный протокол поверх TCP.

  • Оптимизирован для высоких нагрузок и потоковой обработки.
  • Бинарный протокол.
  • Ориентирован на логирование, event streaming, аналитику.
  • Поддерживает партиционирование и репликацию.

Redis Pub/Sub

Redis в контексте брокеров упоминается с оговоркой: у него есть свой протокол и механизм pub/sub, который может использоваться как лёгкая альтернатива брокеру.

  • Работает поверх TCP.
  • Крайне простое подключение: подписка на канал (SUBSCRIBE channel) и отправка сообщений (PUBLISH channel message).
  • Не гарантирует доставку (если консьюмер не подключён — сообщение теряется).
  • Подходит для уведомлений, стриминга небольшого объёма данных, не критичных к потерям.

Резюме

Выбор протокола брокера сообщений зависит от сценария:

ПротоколТипичный брокерСценарий
AMQPRabbitMQ, ActiveMQКорпоративные интеграции, гарантированная доставка
MQTTMosquitto, HiveMQIoT, встраиваемые устройства
STOMPRabbitMQ, ActiveMQПростота и читаемость протокола
Kafka ProtocolApache KafkaВысокие нагрузки, event streaming, аналитика
Redis Pub/SubRedisЛёгкие уведомления, простые сценарии