Какие задачи решает система с RabbitMQ

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

Понимаете ли вы, зачем в системе брокер сообщений и какие гарантии он даёт на самом деле. Типичные уточнения: что будет с сообщением, если воркер упал посреди обработки, и чем RabbitMQ отличается от Kafka.

Как отвечать

RabbitMQ это брокер с моделью «обменник, привязка, очередь»: продюсер публикует в exchange, тот по routing key раскладывает сообщения по очередям, консьюмеры читают из очередей. Основной протокол AMQP 0-9-1, в Python это pika, aio-pika для asyncio, а поверх них Celery и FastStream.

Задачи, которые он решает:

• фоновые задачи: веб-запрос отвечает сразу, а письмо, отчёт или ресайз картинки уходят воркеру. Классика: Celery с RabbitMQ в роли брокера;
• сглаживание пиков: очередь копит сообщения, воркеры разбирают их в своём темпе, база не ложится от всплеска;
• развязка сервисов: отправителю не нужно знать, кто и сколько получателей. Exchange типа fanout раздаёт событие всем, topic работает по шаблону ключа, direct по точному совпадению;
• конкурирующие потребители: несколько воркеров на одной очереди делят нагрузку, а basic_qos(prefetch_count=...) не даёт одному забрать всё;
• отложенные повторы: dead letter exchange плюс TTL дают очередь ретраев без своего планировщика.

Отдельно проговорите надёжность. Сообщение переживёт сбой, только если очередь durable, сообщение persistent, продюсер ждёт publisher confirms, а консьюмер отправляет ack после обработки, а не при получении. Для отказоустойчивости сейчас используют quorum queues, классические зеркальные очереди в ветке 4.x убраны. Гарантия при этом at-least-once, поэтому обработчик обязан быть идемпотентным.

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

Говорят «RabbitMQ гарантирует доставку» без условий. С auto_ack=True сообщение считается доставленным в момент выдачи, и падение воркера его теряет.

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

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