Wiki · Технологии разработки

RabbitMQ

4 мин чтенияАвтор: Сергей ЧерняковСоавторы: Евгений Баев

RabbitMQ – это брокер сообщений с открытым кодом: одни программы отправляют в него сообщения, другие забирают, а брокер хранит их в очередях, пока получатель не обработает и не подтвердит каждое. Код открыт по лицензии MPL 2.0, коммерческую поддержку даёт Broadcom. На октябрь 2026 года актуальна ветка 4.3.

Заказчик обычно встречает RabbitMQ в схеме интеграций. Сайт, 1С, CRM, склад и служба доставки должны обмениваться заказами, остатками и статусами, и подрядчик рисует между ними не стрелки «напрямую», а один блок посередине. Это и есть брокер.

Зачем очередь между сайтом, 1С и CRM

Условный пример. Интернет-магазин передаёт каждый заказ в 1С и в CRM прямыми запросами по API. В пятницу вечером 1С уходит на обновление на два часа. Все заказы за это время либо падают с ошибкой, либо сайт висит, пока ждёт ответа. Утром менеджеры сверяют заказы руками.

С брокером сайт отправляет заказ в RabbitMQ и сразу отвечает покупателю. Сообщение лежит в очереди 1С, пока та недоступна, и в очереди CRM, которая забирает его сразу. Когда 1С вернётся, она получит все накопленные заказы по порядку. Сайт при этом ничего не знает о том, сколько систем ждут его заказы: добавить ещё одного получателя, например склад, можно без переделки сайта.

Схема передачи заказа с сайта в 1С напрямую и через брокер RabbitMQ, где заказ ждёт в очереди, пока 1С недоступна — Заказ с сайта в 1С и CRM

Сама передача данных в 1С, форматы и справочники разобраны в статье Интеграция сайта с 1С. Брокер решает только одну задачу: чтобы сообщение дошло, даже если получатель временно недоступен.

Путь сообщения внутри RabbitMQ

Отправитель публикует сообщение в обменник (exchange) с меткой, например «order.created».
Обменник по правилам маршрутизации раскладывает копии по очередям: одну для 1С, одну для CRM.
Получатель (consumer) забирает сообщение из своей очереди и обрабатывает.
Получатель подтверждает обработку. Только после этого брокер удаляет сообщение. Если получатель упал, не подтвердив, сообщение вернётся в очередь и уйдёт снова.

Основной протокол RabbitMQ называется AMQP 0-9-1, кроме него брокер понимает AMQP 1.0, MQTT и STOMP. Клиентские библиотеки есть для PHP, Python, Java, Go и других языков, так что сайт на 1С-Битрикс и сервис на Python могут работать через одну очередь. В Python-проектах RabbitMQ часто стоит брокером для фоновых задач Celery.

Чем RabbitMQ отличается от Kafka

Это самый частый вопрос, и ответ лежит в том, что происходит с сообщением после чтения.

	RabbitMQ	Apache Kafka
Что после обработки	Сообщение из очереди удаляется	Событие остаётся в журнале на заданный срок
Модель	Очереди и гибкая маршрутизация	Журнал событий, разбитый на разделы
Под какую задачу	Обмен заказами и статусами между системами, фоновые задачи	Большие потоки событий, которые читают несколько систем и перечитывают историю
Порядок	В пределах очереди	В пределах раздела

Граница размыта: в RabbitMQ есть потоки (streams), где сообщения после чтения не удаляются. Но для типовой интеграции сайта с 1С и CRM журнал событий избыточен, а очередь как раз то, что нужно.

Надёжность и мониторинг: что спросить у подрядчика

Чек-лист надёжности RabbitMQ: долговечные и кворумные очереди, подтверждения, очередь для ошибок, мониторинг и закрытый интерфейс — Что спросить у подрядчика про RabbitMQ

Переживут ли сообщения перезагрузку сервера. Для важных данных нужны долговечные очереди и сохраняемые сообщения, а в кластере кворумные очереди, которые копируются на несколько узлов.
Включено ли подтверждение обработки. Без него сообщение считается доставленным в момент отправки, даже если получатель упал.
Куда попадают сообщения, которые не удалось обработать. Иначе одно битое сообщение будет бесконечно возвращаться в очередь.
Кто следит за длиной очередей. Растущая очередь значит, что получатель не справляется или стоит. Документация RabbitMQ рекомендует для мониторинга в продакшене Prometheus и Grafana, а веб-интерфейс управления на порту 15672 удобен для разовой проверки.
Закрыт ли этот интерфейс от интернета и сменены ли стандартные учётные данные.

Рост очередей, REST API и сохранность сообщений

Почему растёт очередь в RabbitMQ и что делать?

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

Как работать с RabbitMQ через REST API?

У RabbitMQ есть HTTP API из плагина управления. Документация описывает его прежде всего как инструмент для диагностики и управления: посмотреть очереди, создать пользователя, проверить состояние узла. Для постоянного обмена сообщениями приложения подключаются к брокеру по AMQP через клиентскую библиотеку.

Что будет с сообщениями, если сервер RabbitMQ перезагрузится?

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

Где смотреть очереди RabbitMQ?

Очереди видно в веб-интерфейсе плагина управления, обычно на порту 15672: число сообщений, скорость, подключённые получатели. Для постоянного наблюдения с графиками и алертами настраивают Prometheus и Grafana.

Обмен сайта с 1С, CRM и другими системами настраиваем при доработке существующего сайта, а за очередями и ошибками интеграций следим на технической поддержке.