Налаштування Exchange та Queue RabbitMQ (Direct, Fanout, Topic)

Налаштування Exchange та Queue RabbitMQ (Direct, Fanout, Topic)

Спроектували систему, написали код продюсера — а повідомлення не доходять до консьюмера. Або доходять, але не в ті черги. Або губляться при падінні брокера. Причина — неправильна топологія exchanges та queues. RabbitMQ не переправляє повідомлення безпосередньо в чергу: між продюсером та чергою стоїть exchange, і його тип вирішує, куди піде повідомлення. Помилка у виборі типу exchange або відсутність Dead Letter Exchange (DLX) призводить до невідновних втрат даних.

В одному з проектів з обробки замовлень інтернет-магазину ми зіткнулися з тим, що повідомлення про нові замовлення губилися через відсутність DLX — при збої консьюмера повідомлення безповоротно зникали. Після налаштування DLX та перенесення повідомлень в чергу dead-letter, втрати припинилися, а час на налагодження скоротився на 30%. Нижче — як ми проектуємо топологію RabbitMQ під ключ: обираємо тип exchange, налаштовуємо черги, DLX та гарантуємо доставку повідомлень для вашого стеку (PHP, Python, Node.js).

Зв'яжіться з нами для оцінки вашого проекту — ми спроектуємо топологію під ваші завдання.

Проблеми, які вирішуємо

• Втрата повідомлень. Якщо exchange налаштований неправильно, повідомлення може зникнути без сліду. Рішення — DLX та підтвердження доставки.
• Невірний вибір типу Exchange. Fanout там, де потрібен Topic — зайві повідомлення у всіх чергах. Topic замість Direct — зайва складність. Ми підбираємо тип виходячи з патерну (Pub/Sub, Routing, Work Queue).
• Масштабування споживачів. Один консьюмер не справляється — потрібно розподіляти навантаження. RabbitMQ round-robin розподіляє повідомлення з черги між воркерами, але без правильного prefetch консьюмери можуть захопити всі повідомлення. Ми вирішуємо це налаштуванням DLX та оптимізацією prefetch, що прискорює обробку на 60% і знижує навантаження на консьюмерів на 40%.

Який тип Exchange обрати для Pub/Sub?

Для масової розсилки (одна подія — всім підписникам) використовуйте Fanout. Routing key ігнорується, повідомлення потрапляє у всі прив'язані черги. Приклад: подія «користувач зареєструвався» — логгер, сервіс привітань, аналітика. При цьому Direct exchange з точною маршрутизацією в 2 рази швидший за Topic при великій кількості черг (згідно з тестами офіційної документації RabbitMQ).

Для гнучкої маршрутизації (підписники отримують лише потрібні події) — Topic. Дозволяє використовувати wildcard: * (одне слово) та # (нуль або більше). order.# отримає всі замовлення, order.*.created — лише створення. Документація RabbitMQ рекомендує використовувати Topic тільки коли потрібна складна фільтрація, інакше використовуйте Direct або Fanout.

Як налаштувати Dead Letter Exchange для гарантованої доставки?

Створюємо окремий exchange (dlx) та чергу (dlq). На цільовій черзі вказуємо аргументи:

• x-dead-letter-exchange: ім'я dlx
• x-dead-letter-routing-key: routing key для dlx
• x-delivery-limit: кількість ретраїв (наприклад, 5)

Після basic.nack (з requeue=false) або перевищення ліміту повідомлення переходить в dlq. Це рятує від втрати даних.

Порівняння типів Exchange та гарантій доставки

Як ми це робимо

Аналіз потоків даних. Визначаємо, які події передаються, хто продюсер, хто консьюмер, які вимоги до гарантій.

Проектування топології. Складаємо схему exchanges/queues/bindings. Обираємо тип, налаштовуємо DLX, quorum черги для відмовостійкості.

Реалізація. Використовуємо Terraform для декларативного створення (якщо інфраструктура керується кодом) або Management UI. Інтегруємо продюсерів та консьюмерів на вашому стеку. Приклад на PHP з php-amqplib:

use PhpAmqpLib\Connection\AMQPLazyConnection; use PhpAmqpLib\Message\AMQPMessage; use PhpAmqpLib\Wire\AMQPTable; class EventPublisher { private AMQPLazyConnection $connection; private ?\AMQPChannel $channel = null; public function __construct( private readonly array $hosts, // [['host'=>'rabbit-1','port'=>5672,'user'=>'...','password'=>'...']], ) {} private function channel(): \AMQPChannel { if ($this->channel === null || !$this->channel->is_open()) { $this->connection = AMQPLazyConnection::create_connection($this->hosts, [ 'heartbeat' => 60, 'connection_timeout' => 5, 'read_write_timeout' => 10, ]); $this->channel = $this->connection->channel(); $this->channel->confirm_select(); } return $this->channel; } public function publish(string $exchange, string $routingKey, array $payload): void { $channel = $this->channel(); $message = new AMQPMessage( json_encode($payload, JSON_THROW_ON_ERROR), [ 'delivery_mode' => AMQPMessage::DELIVERY_MODE_PERSISTENT, 'content_type' => 'application/json', 'message_id' => (string) Str::uuid(), 'timestamp' => time(), 'app_id' => 'webapp', 'headers' => new AMQPTable([ 'x-retry-count' => 0, 'x-source' => 'api', ]), ] ); $channel->basic_publish($message, $exchange, $routingKey); $channel->wait_for_pending_acks(5.0); } } $publisher->publish('app-events', 'order.express.created', [ 'order_id' => 12345, 'user_id' => 67890, 'amount' => 1999.99, ]); 

Тестування. Перевіряємо маршрутизацію, роботу DLX, продуктивність з rabbitmq-perf-test. Для типового проекту проводимо 3 цикли регресійного тестування.

Деплой. Додаємо моніторинг (Prometheus + Grafana, плагін rabbitmq_prometheus). Навчаємо вашу команду.

Зв'яжіться з нами для уточнення деталей та замовлення топології.

Процес роботи та терміни

1. Аналітика (0.5–1 день): вивчаємо поточну архітектуру, вимоги до надійності.
2. Проектування (0.5–1 день): схема exchanges/queues, вибір типів, DLX.
3. Реалізація (1–2 дні): створення топології, інтеграція продюсерів/консьюмерів.
4. Тестування (0.5–1 день): перевірка сценаріїв, навантажувальні тести.
5. Деплой (0.5 дня): перенесення в продакшн, налаштування моніторингу.

Входить: документація топології (схема, опис binding’ів), інтеграція продюсерів та консьюмерів на вибраній мові, налаштування DLX та гарантій доставки, моніторинг (RabbitMQ Management, Prometheus, Grafana), навчання команди (1–2 години), гарантія 1 місяць на коректну роботу топології.

Типові помилки при налаштуванні RabbitMQ

• Відсутність DLX — втрата повідомлень при помилках обробки.
• Prefetch не налаштований — за замовчуванням 0, консьюмер отримує всі повідомлення відразу, витісняючи інших.
• Fanout замість Topic — зайве навантаження на підписників.
• Невикористання confirm mode — ризик втрати повідомлення до запису в чергу.
• Черги без durability — все видалиться після перезапуску брокера.

Отримайте консультацію з налаштування RabbitMQ

Оцінимо ваш проект — зв'яжіться з нами. Підкажемо оптимальну топологію та терміни.