Налаштування 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

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

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

Які проблеми вирішуємо

N+1 запити: головний вбивця швидкості

N+1 — найпоширеніша причина повільних сторінок у Laravel-додатках. Стандартна історія: сторінка працювала нормально на dev з 10 записами, на production з 10 000 — 8-секундне завантаження.

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

Laravel Octane (RoadRunner або Swoole) прибирає overhead bootstrap на кожен HTTP-запит. Приріст: 3–8x на синтетичних бенчмарках, 2–4x на реальних додатках. Важливо: не зберігати стан у статичних змінних — застосовуємо це на проектах >1000 RPS.

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.