Какие архитектурные блоки включает система с брокером RabbitMQ

Что проверяют

Понимаете ли вы модель AMQP 0-9-1: продюсер пишет не в очередь, а в exchange. Следом почти всегда спрашивают, что будет, если потребитель упадёт посреди обработки, и как не потерять сообщение.

Как отвечать

Пройдите путь сообщения по блокам:

• producer: публикует сообщение в exchange с routing key. Для гарантии доставки включают publisher confirms и помечают сообщения persistent;
• connection и channel: одно TCP-соединение на процесс, внутри лёгкие каналы. Открывать соединение на каждое сообщение нельзя;
• exchange: маршрутизатор без хранения. Типы: direct (точное совпадение ключа), topic (шаблоны с * и #), fanout (во все привязанные очереди), headers (по заголовкам). Безымянный default exchange кладёт сообщение в очередь с именем, равным ключу;
• binding: правило, связывающее exchange с очередью;
• queue: хранит сообщения. Для надёжности в кластере берут quorum queues на Raft, классические зеркальные очереди в RabbitMQ 4.x удалены. Для повторного чтения есть streams;
• consumer: подтверждает сообщение ручным ack после обработки, объём выдачи ограничивает prefetch_count через basic_qos;
• dead letter exchange: сюда уходят отклонённые, просроченные по TTL и вытесненные лимитом очереди сообщения. На нём строят отложенные повторы;
• инфраструктура: vhost и права пользователей, кластер из нескольких узлов, management plugin с веб-интерфейсом, метрики для Prometheus.

В Python это pika для синхронного кода, aio-pika для asyncio, а в прикладных задачах часто Celery с RabbitMQ в роли брокера или FastStream. Полезно знать, что Celery по умолчанию подтверждает задачу до выполнения, и для идемпотентных задач включают acks_late.

Где спотыкаются

Говорят, что продюсер кладёт сообщение прямо в очередь, и не могут объяснить, зачем нужен exchange.

Включают auto_ack и теряют сообщения при падении воркера, либо не ставят prefetch_count, и один потребитель забирает себе всю очередь.

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