Очереди и сообщения
Тема дорожной карты · DevOps Engineer
Очереди сообщений — это инфраструктурный слой для асинхронного обмена данными между сервисами. Producer кладёт сообщение в очередь, consumer его забирает — отправитель и получатель не привязаны друг к другу по времени или доступности. Для DevOps это значит: возможность отстреливать долгие задачи в фон без блокировки HTTP-запроса; буферизация всплесков нагрузки; устойчивость к падению потребителей (сообщения не теряются); и переиспользование одного источника событий разными подписчиками (publish-subscribe). Самые ходовые продукты в RF-сегменте — RabbitMQ и Apache Kafka.
Как это работает
RabbitMQ — классический message broker по модели AMQP: producer → exchange → routing → queue → consumer. Брокер хранит сообщения до подтверждения от consumer'а (ack), при отказе пересылает повторно. Подходит для command-style задач: "обработай эту платёжку", "отправь это письмо". Kafka — append-only лог: producer пишет в партиции topic'а, consumer читает по offset'у и сам трекает где он остановился. Сообщения хранятся фиксированный период (часы, дни, бесконечно), могут читаться повторно — это event log, а не очередь в классическом смысле. Подходит для event-streaming, аналитики, межсервисной коммуникации через события.
Когда применять
Очереди нужны, как только HTTP-запрос не может ждать длинного processing'а (email, отчёты, ML-инференс, обработка платежей с третьими сторонами). Также — когда нужно надёжно доставить событие другому сервису без жёсткой временной связи (микросервисная архитектура). Выбор RabbitMQ vs Kafka: RabbitMQ — когда сообщений мало (тысячи/сек), важна индивидуальная обработка и подтверждения; Kafka — когда сообщений много (миллионы/сек), важна история событий и горизонтальное масштабирование. В простых случаях стартовать можно с PostgreSQL-таблицы как очереди (SELECT FOR UPDATE SKIP LOCKED) — не тащите Kafka ради 10 RPS.
Типичные ошибки
Грабли: at-most-once вместо at-least-once (потеряли сообщение при падении consumer'а); отсутствие dead-letter queue (повторные провалы зацикливаются и блокируют очередь); неидемпотентный consumer (одно сообщение обработалось дважды → дублирующая операция в БД); ordering-гарантии в Kafka работают только в пределах одной партиции — нельзя положиться на глобальный порядок; backpressure не настроен (producer пишет быстрее consumer'а, очередь раздувается на 100 ГБ); RabbitMQ без cluster'а или с queue не зеркальной — падение одного узла теряет сообщения.