RabbitMQ¶

Тип материала: архитектурный разбор. Схемы и примеры иллюстративные, если не указано иное.

Область версий: RabbitMQ 4.1.0, AMQP0-9-1; quorum/classic/stream различаются. Проверка источников: 2026-11-02. Baselines не объявляются latest/security recommendations.

Архитектура и роль¶

FACT. AMQP exchanges маршрутизируют messages в queues по bindings; consumers получают deliveries. Queue type — существенная часть architecture: classic, quorum и streams имеют разные durability/replay/replication contracts. Classic mirrored queues удалены в4.0, не использовать старые HA инструкции для4.1.

Внутренние механизмы и движение данных¶

Publisher отправляет exchange, routing находит queues, storage queue подтверждает запись согласно типу/настройкам. Consumer ack удаляет успешно обработанную delivery из обычного queue lifecycle. Publisher confirms и consumer acknowledgements независимы: первый подтверждает broker-side acceptance, второй — processing consumer.

flowchart TB
  Publisher --> Exchange[Exchange and bindings]
  Exchange --> Queue[Selected queue type]
  Queue --> Confirm[Publisher confirm boundary]
  Queue --> Consumer[Delivery with manual ack]
  Consumer --> DB[External commit]
  DB --> Ack[Consumer acknowledgement]

Ordering и guarantees¶

Quorum queues используют Raft/majority protocol; confirmed message durability имеет documented failure assumptions. Classic queue не получает replication только от durable=true. Unroutable publish требует mandatory/returns либо alternate exchange: успешный publish/confirm не обязательно означает нужный consumer получил record. Confirms.

Версия и первичная документация.

Масштабирование и backpressure¶

Prefetch ограничивает unacked deliveries и memory/work pressure. Слишком большой prefetch увеличивает unfairness и recovery bursts; маленький может недоиспользовать worker. Один queue leader остаётся bottleneck; множество queues/shards усложняет routing/global ordering. Streams предлагают иную retention/replay модель.

Failure / recovery / replay¶

Consumer crash до ack вызывает redelivery; DB commit до ack требует idempotency. Requeue loop poison message может бесконечно грузить очередь. Dead-lettering имеет собственный delivery contract: для quorum at-least-once DLQ надо настроить соответствующую strategy/overflow; default нельзя выдавать за гарантированную передачу. Quorum4.1.

Версия и первичная документация.

Эксплуатация и мониторинг¶

Ready/unacked/age, redeliveries, publisher confirm latency/errors, unroutable returns, quorum member health, disk/memory alarms, connection/channel churn. Channel delivery tags имеют scope channel; ack на другом channel ошибочен. Мониторить DLQ без обработки как отдельную растущую очередь.

Ограничения и критерии выбора¶

Выбирать task/work routing и bounded delivery lifecycle с acknowledgements. Для долгого historical replay несколькими независимыми аналитическими consumers сравнить Kafka/Pulsar/streams. «RabbitMQ всегда без replay» неверно из-за stream queue model, но обычные acked queues не Kafka log.

FinTech / iGaming и реальные источники¶

INFERENCE: document verification jobs, payment-provider requests и notifications с внешними idempotency keys. Передача команды payout не доказывает выполнения ledger/провайдера. Конкретный company-specific guarantee baseline4.1 UNKNOWN.

Практический пример¶

Протокол retry/DLQ сравнивается с Kafka executable consumer, но API acknowledgements не копируются между brokers. Для AMQP дополнительно задать queue type, durable/persistent messages, confirms, mandatory и consumer manual ack.

Типичные ошибки проектирования¶

durable queue как replicated queue; confirm как consumer success; ack до durable effect; бесконечный nack/requeue; DLX всегда at-least-once.

Вопросы на собеседовании¶

Confirm и ack одно? Нет, разные участники и boundaries.

Очередь гарантирует order обработки? Delivery order может отличаться от completion при нескольких consumers/requeue.

Как убрать poison loop? Bounded retries + durable quarantine с owner и проверенным publish outcome.

Практические упражнения¶

Нарисуйте publish unroutable, consumer DB commit/lost ack и DLX outage. Для каждого укажите, где возможны loss/duplicate и какой signal нужен.