Гайды

RabbitMQ: установка и базовые обменники

Docker и management UI, exchange → queue, direct/fanout/topic, персистентность, prefetch и мониторинг.

~10 мин чтения

RabbitMQ: установка и базовые обменники

RabbitMQ — брокер сообщений на модели AMQP 0-9-1: издатель не пишет в «очередь» напрямую, а в exchange, который маршрутизирует в одну или несколько очередей по bindings. Этот гайд — установка и модель exchange → queue; сравнение с Kafka — RabbitMQ vs Kafka.

1. Установка (Docker)

bash

docker run -d --hostname rabbit --name rabbitmq \
  -p 5672:5672 -p 15672:15672 \
  -e RABBITMQ_DEFAULT_USER=admin -e RABBITMQ_DEFAULT_PASS=secret \
  rabbitmq:3-management

5672 — AMQP для приложений.
15672 — веб-UI management plugin.

Прод: TLS, отдельные пользователи, vhost на сервис, лимиты памяти (vm_memory_high_watermark).

2. Основные сущности

Сущность	Роль
Exchange	Точка входа сообщений; тип определяет маршрутизацию
Queue	Буфер FIFO (с оговорками по приоритетам), хранение до consume
Binding	Правило «exchange + routing key → queue»
Channel	Лёгкое мультиплексирование поверх одного TCP-соединения
Consumer	Подписка на очередь (push / prefetch)

3. Типы exchange

Тип	Маршрутизация
direct	Routing key точно совпадает с ключом binding
fanout	Копия во все привязанные очереди (игнор routing key)
topic	Паттерны `*` (одно слово) и `#` (хвост)
headers	По совпадению заголовков (редко)
default	Имя `""`; routing key = имя очереди (простой RPC-стиль)

4. Мини-сценарий: fanout логов

Exchange logs.fanout типа fanout.
Очереди logs.ui, logs.api с binding без ключа.
Publish в logs.fanout → обе очереди получают копию.

5. Topic routing (пример)

Exchange orders.events типа topic.
Binding: queue orders.de с ключом orders.de.*.
Сообщение с routing key orders.de.created попадёт в эту очередь.

6. Персистентность

Durable exchange/queue переживают рестарт брокера при persistent сообщениях (delivery_mode=2). Transient — быстрее, но при падении — потеря.

Publisher confirms — брокер ACK'ит запись на диск/реплику; повышает надёжность.

Dead-letter exchange (DLX): у очереди укажите x-dead-letter-exchange и при необходимости x-dead-letter-routing-key; сообщения после reject/nack или TTL попадут в отдельную очередь для разбора, а не потеряются.

7. Prefetch и справедливость

basic.qos(prefetch_count) — сколько unacked сообщений consumer держит на себе. Важно для равномерной нагрузки между worker'ами и защиты от OOM.

8. Управление и мониторинг

UI: очереди, rates, unacked, memory alarm.
Prometheus + rabbitmq_exporter для алертов на disk free, queue depth, connection churn.

9. Чек-лист

Отдельный vhost и пользователь с минимальными правами.
Durable + persistent для критичных сообщений.
Prefetch настроен под время обработки.
Политика TTL/dead-letter для зависших сообщений (в документации RabbitMQ — DLX).
Для критичных очередей рассмотрите quorum queues (Raft) вместо классических mirrored policy — проще эксплуатация на новых версиях кластера.

Дальше: RabbitMQ vs Kafka · NATS · Тег RabbitMQ