🔼AMQP, MQTT и STOMP
AMQP, MQTT и STOMP — независимые протоколы обмена сообщениями прикладного уровня Приложения используют их, чтобы общаться с брокером сообщений поверх TCP
✖️ это не версии одного протокола и не преемники друг друга ✔️ каждый создавался под свою задачу:
🟣 AMQP — надёжная корпоративная интеграция и гибкая маршрутизация 🟣 MQTT — лёгкий обмен с устройствами в нестабильной сети 🟣 STOMP — простой текстовый обмен
Что общего
🟣 все решают одну задачу: асинхронный обмен сообщениями через брокера 🟣 работают поверх TCP. Могут подниматься поверх WebSocket — так браузерный клиент общается с брокером через любой из трёх протоколов 🟣 мультипротокольные брокеры: 🟡RabbitMQ поддерживает AMQP 0-9-1 и AMQP 1.0 нативно 🟡MQTT и STOMP — через плагины поверх внутренней AMQP-модели 🟡ActiveMQ тоже понимает все три.
AMQP
AMQP (Advanced Message Queuing Protocol) — открытый бинарный протокол прикладного уровня
🟣Используется для передачи сообщений между компонентами через брокера.
🟣Это wire-level протокол: стандарт описывает точный формат данных, которые клиент и брокер передают по сети.
🟣Клиент на любом языке, реализующий этот формат, совместим с любым брокером той же версии — без фирменных SDK и «мостов»
👇 Стандартный порт — 5672
Модель AMQP 0-9-1
На этой версии построен RabbitMQ, и чаще всего под «AMQP» в интеграциях понимают именно её. Протокол описывает сущности брокера — топологию, которую стороны создают командами:
🔘Exchange (обменник): принимает сообщения от продюсеров и распределяет по очередям. Сам ничего не хранит 🔘Queue (очередь): именованный буфер, где сообщения хранятся, пока их не заберут потребители 🔘Binding (привязка): правило, связывающее exchange с queue. Может включать binding key 🔘Routing key: метка, которую продюсер прикладывает к сообщению, а exchange учитывает при маршрутизации
Тип exchange задаёт правило маршрутизации:
🟣direct: точное совпадение routing key и binding key — сообщение попадает в конкретную очередь. 🟣fanout: ключ игнорируется, копия уходит во все привязанные очереди — рассылка всем подписчикам. 🟣topic: сопоставление по маске. Ключ — слова через точку (orders.europe.created). * заменяет ровно одно слово, # — ноль и более слов. 🟣headers: маршрутизация по заголовкам сообщения, без routing key.
AMQP 1.0
AMQP 1.0 — не следующая версия 0-9-1, а другой протокол ✖️ С 0-9-1 его не связывает ничего, кроме имени 👇 1.0 описывает только передачу и не навязывает модель брокера: гарантии доставки настраиваются на каждом канале отдельно
Гарантии доставки в AMQP 0-9-1
Базовая публикация не подтверждается брокером: без дополнительных механизмов это «отправил и забыл» (at most once)
Надёжность собирается из частей:
🔘publisher confirms: брокер подтверждает приём каждого сообщения (расширение RabbitMQ) 🔘consumer acknowledgements: сообщение считается обработанным только после подтверждения потребителем. Без подтверждения брокер доставит его повторно 🔘persistent-сообщения и durable-очереди: защита от потери при перезагрузке брокера
👇 Комбинация даёт семантику at least once (как минимум один раз) Её цена — дубликаты, поэтому потребитель должен быть идемпотентным
Когда использовать AMQP
- корпоративная интеграция и микросервисы: сложная маршрутизация, разделение и слияние потоков событий - приоритизация, транзакционность (несколько публикаций «всё или ничего») - гарантии доставки
Брокеры
🔘RabbitMQ 🔘Azure Service Bus (основной протокол — AMQP 1.0) 🔘ActiveMQ
MQTT
MQTT — лёгкий бинарный протокол публикации/подписки для устройств с ограниченными ресурсами и нестабильной сетью 👇 Стандартные порты — 1883 (TCP) и 8883 (TLS)
Архитектура
Издатель ➡️ брокер ➡️ подписчики
🟣 У клиентов нет адресов: издатель публикует сообщение брокеру, тот фильтрует по топикам и рассылает подписчикам 🟣 Издатель и подписчик не знают друг о друге.
Топики
Данные адресуются топиками — иерархическими метками
Уровни разделяются слэшем: 🟣factory/line2/temperature — топик датчика температуры второй линии цеха. 🟣Подписка — на точный топик или маску: 🟣factory/+/temperature — датчики температуры всех линий (+ заменяет ровно один уровень); 🟣factory/# — всё производство (# заменяет ноль и более уровней, включая сам factory).
Формат payload (JSON, бинарные данные) стандарт не описывает — это договорённость сторон
Гарантии
QoS (Quality of Service) действует на каждом участке отдельно Итоговый QoS для подписчика — минимальный из QoS публикации и QoS подписки Поэтому идемпотентность потребителя остаётся актуальной даже при QoS 2 («ровно один раз»).
Механизмы MQTT
🟣Retained-сообщения: брокер хранит последнее сообщение топика и выдаёт его каждому новому подписчику Подключился — сразу получил актуальное состояние 🟣LWT (Last Will and Testament, «завещание»): при подключении клиент оставляет брокеру сообщение, которое тот опубликует при нештатном обрыве связи Типовой паттерн — топик статуса устройства со значениями online/offline 🟣 Persistent-сессии: брокер помнит подписки офлайн-клиента и накапливает для него сообщения QoS 1/2.
Когда использовать MQTT
🟡 IoT и телеметрия: датчики, телематика, умные здания и производства 🟡 Мобильные приложения, где важны расход трафика 🟣Если устройство на сетевом питании отправляет данные раз в час, HTTP может оказаться проще
Брокеры
Eclipse Mosquitto, EMQX, HiveMQ
STOMP
STOMP (Streaming Text Oriented Messaging Protocol) — простой текстовый фреймовый протокол по мотивам HTTP Единственный из тройки, которым можно пользоваться вручную: сессию с брокером можно открыть даже через telnet
🟣Общение идёт фреймами: команда, заголовки вида «ключ: значение», тело 🟣Ключевое отличие: у STOMP нет собственной модели маршрутизации. Destination — непрозрачная строка, семантику которой задаёт брокер:
- в RabbitMQ /queue/имя — разделяемая очередь - /topic/ключ — публикация в topic-exchange - /exchange/имя/ключ — произвольный exchange
✅ Есть подтверждения (ACK/NACK) и транзакции (BEGIN/COMMIT/ABORT) — группа отправок «всё или ничего» ✖️ Уровней QoS, как в MQTT, нет
Когда использовать STOMP
🟣Браузерные клиенты поверх WebSocket: чаты, уведомления, обновления в реальном времени 🟣Скриптовые языки, быстрые прототипы, ручная отладка 🟡Для высоконагруженных прод-интеграций бинарные AMQP и MQTT эффективнее
Реализации
👇 Плагин RabbitMQ (TCP-порт 61613, для браузеров — Web STOMP), 👇 Apache ActiveMQ и Artemis 👇 встроенный брокер Spring
Типичные ошибки
✖️ «Это конкуренты Kafka» → это протоколы, а Kafka — платформа потоковой обработки со своим бинарным протоколом. Сравнивать надо брокеров: Kafka vs RabbitMQ ✖️ «AMQP — это брокер» → AMQP — протокол; брокеры (RabbitMQ, Qpid, ActiveMQ) — его реализации ✖️ «MQTT — это очередь» → нет: это pub/sub «многие ко многим», а не очередь точка-точка ✖️ «AMQP 1.0 — развитие 0-9-1» → два разных протокола под одним именем
📎 Материалы 1. Протокол MQTT: концептуальное погружение 2. AMQP vs. MQTT: 9 ключевых различий 3. Краткий обзор протокола AMQP 4. Сравнение популярных брокеров MQTT с открытым исходным кодом
📚 Книги RabbitMQ для профессионалов — Гэвин Рой
#проектирование #интеграции
➿➿➿➿➿➿➿➿➿➿
🧑🎓 Более поробное сравнение в базе знаний по системному анализу