Зачем нужен брокер очередей RabbitMQ

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

Понимаете ли вы, какую проблему решает брокер: развязку сервисов, фоновую обработку и сглаживание пиков нагрузки. И знаете ли, как RabbitMQ устроен внутри, а не только что «туда кладут сообщения». Следом почти всегда спрашивают, чем он отличается от Kafka и что будет, если воркер упал посреди обработки.

Как отвечать

Начните с задачи. Веб-запрос не должен ждать, пока отправится письмо или пережмётся картинка: обработчик кладёт задачу в очередь и сразу отвечает, а воркеры разбирают очередь в своём темпе. Если трафик вырос втрое, растёт очередь, а сервис продолжает отвечать.

Дальше модель RabbitMQ (протокол AMQP 0-9-1):

• exchange: продюсер пишет не в очередь, а в обменник. Типы: direct по точному ключу, topic по шаблону ключа вроде order.*.paid, fanout во все привязанные очереди, headers по заголовкам;
• binding и queue: привязка связывает обменник с очередью, очередь хранит сообщения до получения;
• надёжность: долговечная очередь и persistent-сообщения, publisher confirms у отправителя, ручной ack у потребителя. Неподтверждённое сообщение вернётся в очередь, если воркер упал;
• управление потоком: prefetch_count через basic_qos не даёт одному воркеру набрать сотню задач, пока остальные простаивают;
• ошибки: dead letter exchange для сообщений, которые не удалось обработать, и TTL.

Для отказоустойчивости сейчас берут quorum-очереди на Raft, классические зеркальные очереди в RabbitMQ 4 убраны. Из Python с брокером работают через Celery (RabbitMQ его классический брокер), pika, асинхронный aio-pika или FastStream.

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

Говорят, что RabbitMQ гарантирует доставку ровно один раз. Реальная гарантия с ack и confirms это «хотя бы один раз», поэтому обработчик обязан быть идемпотентным.

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

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