RabbitMQ

Открытый брокер сообщений и потоковой передачи для распределённых систем: гибкая маршрутизация, реплицируемые quorum-очереди и стримы, подтверждения доставки. Для микросервисной архитектуры, фоновых задач, RPC и IoT.

РазработчикRabbitMQ

Что такое RabbitMQ

RabbitMQ — это open-source брокер сообщений, который выступает в роли цифрового диспетчера между компонентами распределённых систем. Вместо того чтобы заставлять сервисы общаться напрямую и ждать ответа друг друга, они отправляют сообщения в очередь, а RabbitMQ гарантированно доставляет их адресату. Это позволяет развязать жёсткие связи в архитектуре: производитель не знает, кто и когда обработает его запрос, а потребитель не зависит от доступности источника.

Написанный на Erlang, RabbitMQ изначально создавался под протокол AMQP 0-9-1, но сегодня поддерживает MQTT, STOMP и собственный потоковый протокол. Он одинаково хорошо работает и в микросервисном облаке, и на «железном» сервере в локальной сети.

Ключевые возможности

Гибкая маршрутизация — обменники (exchanges) с типами direct, topic, fanout и headers позволяют построить любую логику доставки: от широковещательной рассылки до адресной фильтрации по ключам.
Quorum-очереди — реплицируемые очереди на основе алгоритма Raft, устойчивые к потере данных и сбоям узлов. Замена классическим mirrored-очередям.
Потоковые стримы — append-only логи для сценариев, где нужно многократно перечитывать события или вести историю. Стримы не удаляют сообщения сразу после чтения.
Подтверждения доставки — ручной и автоматический ack, механизм dead-letter exchanges для «битых» сообщений и отложенные очереди через TTL.
Плагинная архитектура — консоль управления, шардирование, федерация и кластеризация подключаются как плагины без пересборки ядра.
Мониторинг — встроенная веб-админка, метрики через Prometheus, трассировка сообщений через Firehose.

Кому подойдёт

RabbitMQ — универсальный выбор для команд, которые уже используют языки с богатыми клиентскими библиотеками (Java, Go, Python, .NET, PHP). Это классический вариант для:

Микросервисной архитектуры — асинхронные вызовы между сервисами, event-driven взаимодействие, сага-паттерны.
Фоновых задач — обработка изображений, отправка email, генерация отчётов. Задачи ставятся в очередь, воркеры разбирают их по мере готовности.
RPC-вызовов — синхронный запрос-ответ поверх очередей с корреляционными идентификаторами.
IoT-шлюзов — приём телеметрии с устройств через MQTT с последующей маршрутизацией в аналитику.
Интеграции с legacy-системами — там, где нужен проверенный временем протокол AMQP, а не новомодные Kafka-подходы.

Плюсы и минусы

Плюсы:

Зрелость: проект живёт с 2007 года, огромное комьюнити и документация.
Простота старта: поднять узел можно за 15 минут, есть Docker-образ.
Низкая задержка при высокой пропускной способности (до десятков тысяч сообщений в секунду).
Кроссплатформенность и поддержка всех основных языков.

Минусы:

Сложная маршрутизация при большом количестве обменников превращается в «спагетти».
Пропускная способность ниже, чем у Kafka, при хранении огромных логов.
Кластеризация требует аккуратности: Erlang-узлы чувствительны к сетевым таймаутам.
Нет встроенного механизма партиционирования в стиле Kafka — масштабирование через шардинг-плагин ограничено.

Частые вопросы

В чём разница между RabbitMQ и Kafka?

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

Что такое dead-letter exchange и зачем он нужен?

Это «карантин» для сообщений, которые не удалось обработать после нескольких попыток. Вы настраиваете отдельную очередь, куда RabbitMQ автоматически перенаправляет «битые» сообщения. Это позволяет не терять данные и анализировать причины сбоев.

Как обеспечить доставку без потерь?

Используйте publisher confirms на стороне отправителя, quorum-очереди (вместо классических) и ручной ack с retry-логикой на стороне потребителя. Также стоит настроить персистентность сообщений и не полагаться на auto-delete очереди.

Можно ли использовать RabbitMQ для потоковой аналитики в реальном времени?

Да, с оговорками. Стримы RabbitMQ поддерживают replay событий и группы потребителей, но если вам нужны окна, агрегации и обработка миллионов событий в секунду — лучше присмотреться к Kafka или Pulsar.

Часто задаваемые вопросы

Сколько стоит RabbitMQ?

Открытая версия бесплатна: она распространяется под лицензией Mozilla Public License 2.0, и лицензия не ограничивает количество узлов, очередей или подключений. Платить нужно только за коммерческую сборку Tanzu RabbitMQ, но её стоимость на сайте не публикуется — цену запрашивают у отдела продаж Broadcom.

Какие протоколы поддерживает RabbitMQ?

С версии 4.0 основным протоколом стал AMQP 1.0 — он работает без включения плагинов. Также поддерживаются исторический AMQP 0-9-1, MQTT версий 3.1, 3.1.1 и 5.0, STOMP, собственный протокол потоков и передача AMQP 1.0, MQTT или STOMP поверх WebSocket. Отправлять и получать сообщения можно и через HTTP API плагина управления.

Что случилось с зеркалированием очередей в RabbitMQ 4?

Классическое зеркалирование очередей удалено начиная с релиза 4.0. Вместо него доступны два реплицируемых типа: quorum-очереди на алгоритме консенсуса Raft — рекомендованный вариант для отказоустойчивых очередей, и потоки, которые лучше подходят для повторного чтения и больших накопленных объёмов. Команда проекта выпустила инструменты миграции, в том числе для сине-зелёного развёртывания.

Чем Tanzu RabbitMQ отличается от бесплатной версии?

Коммерческая сборка добавляет круглосуточную поддержку от инженеров проекта и продлённый жизненный цикл версий. Технически в неё входят аварийное восстановление с репликацией схемы и данных в резервный кластер, соответствие FIPS 140-2, прокси OAuth 2.0, сканирование уязвимостей, сжатие внутрикластерного трафика, журналирование действий, распределённые shovel-соединения и отложенные сообщения с репликацией.

Какая версия Erlang нужна для RabbitMQ?

Требования жёсткие и зависят от сборки. Для версий 4.3.3 и 4.2.9 подходит только Erlang/OTP ветки 27: минимум 27.0, максимум 27.x. Для более ранних 4.3.0–4.3.2 и 4.2.0–4.2.8 минимальной считается 26.2. Erlang 28 поддержан частично и рекомендован только для новых кластеров, а не для обновления существующих.

Как долго поддерживается версия 4.3?

Бесплатная поддержка версии 4.3 со стороны сообщества заканчивается 30 ноября 2026 года, коммерческая в рамках Tanzu RabbitMQ — 30 апреля 2028 года. У версии 4.2 сроки другие: 31 июля 2026 года и 30 июня 2030 года соответственно. Планировать обновление стоит с оглядкой на эти даты, потому что после окончания срока исправления безопасности для ветки не выпускаются.

Как развернуть RabbitMQ и чем его мониторить?

Брокер разворачивается в облаке, на собственных серверах и на локальной машине; для Kubernetes есть официальный оператор кластера, а у сообщества — образ Docker. У AWS доступен управляемый брокер Amazon MQ с движком RabbitMQ. Для наблюдения в комплект входит плагин rabbitmq_management с веб-интерфейсом и HTTP API, а для продакшена рекомендована штатная связка с Prometheus и Grafana, доступная с версии 3.8.

Куда сообщать об уязвимости в RabbitMQ?

Уязвимости принимаются только приватно: через раздел Security нужного репозитория на GitHub кнопкой Report a vulnerability либо письмом на tnz-rabbitmq-core.pdl@broadcom.com. Публиковать их в открытых issue, рассылках и Discord правилами проекта запрещено. Готовые бюллетени собраны на странице безопасности сайта, а коммерческим клиентам Broadcom дополнительно раскрывает уязвимости в зависимостях и в среде выполнения Erlang.