RabbitMQ
Тема дорожной карты · Backend разработчик
RabbitMQ — зрелый open-source брокер сообщений, реализующий протокол AMQP и обеспечивающий гибкий, надёжный обмен сообщениями между бэкенд-сервисами через мощную модель exchange, queue и binding, поддерживающую паттерны fan-out, маршрутизации по топику и прямой доставки. RabbitMQ широко применяется в микросервисных архитектурах, где сервисам нужно взаимодействовать асинхронно — REST API-бэкенд публикует событие в RabbitMQ exchange, а несколько нижестоящих потребителей (биллинг, уведомления, аналитика) каждый получают собственную копию через привязанные очереди, не зная ничего о потребителях. Ключевые возможности надёжности: долговечные сообщения, подтверждения (ack/nack), dead-letter exchanges (DLX) для обработки неудавшихся сообщений и настройки prefetch потребителей, предотвращающие перегрузку медленных воркеров быстрыми производителями — что делает RabbitMQ операционно предсказуемым по сравнению с Redis pub/sub для критически важных рабочих процессов. Python-бэкенды используют pika или aio-pika (asyncio), Node.js — amqplib, Java — spring-amqp, Go — amqp091-go — все органично интегрируются с Celery как брокером задач или непосредственно в сервис-к-сервис событийность. RabbitMQ развёртывается в Docker-контейнерах или Kubernetes через RabbitMQ Cluster Operator; его управляющий UI и плагин Prometheus предоставляют глубины очередей и скорости сообщений для алертинга при отставании потребителей.
Как это работает
RabbitMQ использует кеши (Redis, Memcached, in-process LRU) чтобы избежать дорогого DB или compute, и очереди (Redis Streams, RabbitMQ, Kafka, SQS) чтобы развязать медленную async-работу от request-пути. Стратегии инвалидации кеша: TTL (истечение по времени), write-through (обновлять кеш на запись), event-driven (инвалидация на связанное изменение), cache-aside (читаем кеш, fallback на БД). Паттерны очередей: work queues, pub/sub, exactly-once vs at-least-once.
Когда применять
Кеш — когда замер показывает повтор дорогого compute; никогда "превентивно". TTL-кеш — для данных с допустимой staleness (5-60 секунд закрывает большинство кейсов). Очереди — когда запрос триггерит работу, не помещающуюся в response window (отправка email, обработка файлов, вызовы third-party): возвращайте 202 Accepted + status URL. Consumers очередей — это сервисы со своим мониторингом + репликами.
Типичные ошибки
Ловушки RabbitMQ: stale-кеш, потому что забыли инвалидировать на связанном пути (знаменитая "две сложные проблемы"); cache stampede, когда ключ протух и N запросов одновременно бьют в БД (stale-while-revalidate или singleflight); at-least-once очереди без идемпотентных consumer (дубль emails/charges); не мониторите lag очереди (тихий backlog растёт, потом взрывается).