RabbitMQ
Тема дорожной карты · DevOps Engineer
RabbitMQ — message broker с открытым исходным кодом на Erlang, реализующий протокол AMQP 0-9-1 (и опционально MQTT, STOMP). Это рабочая лошадка для очередей в большинстве классических enterprise-сетапов: банкинг, логистика, обработка задач, асинхронные интеграции между сервисами. По сравнению с Kafka — проще для команд, не работавших с распределёнными логами; даёт богатую модель маршрутизации (exchange types), per-message acknowledgements и поддержку priorities. По умолчанию ставится одной командой apt install rabbitmq-server, плагин management UI даёт удобный веб-интерфейс на порту 15672.
Как это работает
Модель: producer публикует сообщение в exchange, exchange по правилам bindings направляет его в одну или несколько queues, consumer забирает из очереди. Типы exchange: direct (точное совпадение routing key), fanout (всем подвешенным очередям), topic (по паттерну, order.*.created), headers (по заголовкам). Сообщение в очереди живёт до ack от consumer'а (basic.ack) или nack (basic.nack, перенаправление в DLQ). Persistence — флаги durable (очередь переживает рестарт), persistent (сообщение пишется на диск). Cluster: несколько нод объединяются, mirrored queues (или quorum queues в 3.8+) реплицируют сообщения для устойчивости к падению узла.
Когда применять
RabbitMQ — правильный выбор когда: волю миллионы сообщений в день, а не миллиарды; нужны сложные правила маршрутизации (одно сообщение в N очередей по разным критериям); каждое сообщение — отдельная задача с подтверждением (платежи, заказы, нотификации); консьюмеры на разных языках (есть клиенты для всего); важна гибкость over throughput. Не подходит когда: вам нужны миллионы событий/сек (Kafka); нужно перечитывать историю событий (Kafka, RabbitMQ не event log); нужно exact-event ordering по тысячам ключей.
Типичные ошибки
Грабли: не выставленный prefetch_count (consumer забирает 1000 сообщений в буфер и держит их, пока обрабатывает одно — остальные простаивают); забытое объявление очереди как durable=true (рестарт брокера = потеря всех очередей); auto-ack включён (сообщение считается обработанным до завершения работы — потеря при падении consumer'а); отсутствие cluster (single-node RabbitMQ = single point of failure); забыли настроить DLQ (poison-message крутится бесконечно); забили диск unbounded-очередью (брокер останавливает все publish'и).