Архитектура и базовые примитивы RabbitMQ

RabbitMQ в экосистеме AMQP: протокол, топология и роль брокера

Парадокс, на котором «сыплются» многие кандидаты на технических собеседованиях, звучит так: в RabbitMQ отправитель (Producer) никогда не отправляет сообщения напрямую в очередь. Несмотря на слово «Queue» в названии технологии, прямая запись в очередь архитектурно невозможна. Чтобы понять, почему это так и как на самом деле движутся данные, нам необходимо погрузиться в стандарт, на котором построен этот брокер.

AMQP 0-9-1: Правила игры

RabbitMQ — это не просто самостоятельная программа с придуманной «на коленке» логикой. Это эталонная реализация открытого стандарта AMQP (Advanced Message Queuing Protocol), а конкретно его версии 0-9-1.

Если HTTP определяет, как браузер общается с веб-сервером, то AMQP определяет, как бизнес-приложения общаются с брокером сообщений. Но у AMQP есть важное отличие. Он стандартизирует не только сетевой формат передачи байтов (wire-level protocol), но и внутреннюю архитектуру самого брокера.

Протокол жестко диктует, какие логические компоненты должны существовать внутри сервера и как они обязаны взаимодействовать. Эта внутренняя структура называется моделью AMQP.

> Модель AMQP гарантирует, что логика маршрутизации отделена от логики хранения. Это позволяет создавать гибкие сценарии доставки без изменения кода самих приложений.

Архитектурные примитивы: Точка обмена и Привязка

Из прошлого курса вы уже знаете, что такое Producer, Consumer и Queue. Очередь — это буфер, где сообщения ждут обработки. Но как сообщение находит правильную очередь? В модели AMQP между Producer и Queue существует промежуточный слой маршрутизации.

!Топология AMQP 0-9-1

В основе топологии RabbitMQ лежат три новых для нас примитива:

Exchange (Точка обмена) — это почтовый сортировочный центр брокера. Producer отправляет сообщения только в Exchange. Задача Exchange — принять сообщение, изучить его метаданные и решить, в какие очереди его нужно скопировать. Сам Exchange не хранит сообщения (у него нет памяти или дискового пространства), он лишь исполняет алгоритм маршрутизации.

Binding (Привязка) — это правило маршрутизации, связывающее Exchange и Queue. Если Exchange — это сортировочный центр, то Binding — это маршрутный лист, который говорит: «сообщения с определенными признаками нужно класть вот в эту очередь». Между одним Exchange и одной Queue может быть несколько привязок.

Routing Key (Ключ маршрутизации) — это короткая строка в метаданных сообщения, которую Producer прикрепляет к Payload перед отправкой. Это «адрес на конверте».

Математика маршрутизации

Процесс принятия решения внутри брокера можно описать простой функцией, где Точка обмена () использует Ключ маршрутизации () и набор Привязок (), чтобы определить целевое множество Очередей ():

Если оказывается пустым (ни одна привязка не подошла), сообщение по умолчанию просто уничтожается (drop), так как Exchange не умеет хранить данные.

Полный жизненный цикл маршрутизации

Давайте соберем все примитивы вместе и проследим путь сообщения. Представьте систему e-commerce, где микросервис корзины (Producer) уведомляет систему о новой покупке.

Генерация: Producer формирует сообщение. В Payload лежит JSON с данными заказа, а в метаданные добавляется Routing Key, например, order.created.

Публикация: Producer устанавливает TCP-соединение с RabbitMQ и отправляет сообщение в заранее известный ему Exchange (назовем его shop_events). На этом работа Producer закончена (fire-and-forget).

Оценка (Routing): Exchange shop_events получает сообщение. Он просматривает свой внутренний список Bindings.

Копирование: Exchange видит, что очередь warehouse_queue имеет Binding, совпадающий с ключом order.created, и очередь analytics_queue тоже имеет такой Binding. Exchange создает две копии сообщения и кладет по одной в каждую очередь.

Хранение и потребление: Сообщения лежат в очередях (FIFO), пока Consumer (сервис склада и сервис аналитики) не заберут их для обработки.

!Процесс маршрутизации сообщения в RabbitMQ

Зачем нужна такая сложность?

На первый взгляд, введение Exchange и Binding кажется избыточным. Почему бы Producer просто не писать напрямую в warehouse_queue?

Ответ кроется в максимальной архитектурной гибкости. Если завтра бизнесу понадобится добавить третий сервис (например, сервис отправки SMS-чеков), нам не придется менять код Producer. Мы просто создадим новую очередь sms_queue в RabbitMQ и добавим новый Binding к существующему Exchange. Producer продолжит отправлять одно сообщение в Exchange, а брокер сам начнет размножать его на три очереди.

Разделение на Exchange (маршрутизация) и Queue (хранение) — это фундамент, который делает RabbitMQ одним из самых мощных инструментов для реализации событийно-ориентированной архитектуры. В следующих главах мы разберем, что алгоритмы маршрутизации внутри Exchange бывают разными, и научимся применять их для решения сложных бизнес-задач.

Жизненный цикл сообщения: от Producer до физической очереди

Если вы отправите сообщение в RabbitMQ, а внутри брокера не окажется ни одной очереди, готовой его принять, брокер молча уничтожит это сообщение. Никаких ошибок, никаких сбоев — это штатное поведение системы. Чтобы понять, почему это так, и научиться контролировать каждый шаг ваших данных, мы должны препарировать жизненный цикл сообщения.

Мы проследим путь одного байт-массива с момента его зарождения в коде Producer до момента, когда он физически осядет в оперативной памяти сервера RabbitMQ.

Шаг 1. Рождение и упаковка (Producer)

Как мы выяснили ранее, Producer не взаимодействует с очередями напрямую. Его задача — сформировать пакет данных и передать его брокеру. На этом этапе формируется структура, состоящая из двух частей:

Payload (Полезная нагрузка) — ваши бизнес-данные (например, JSON с информацией о регистрации пользователя). Для RabbitMQ это просто массив байтов, он не пытается его парсить.

Properties (Свойства AMQP) — стандартизированные метаданные.

Именно в свойствах Producer задает Routing Key — важнейший параметр, который определит судьбу сообщения. Кроме того, здесь указываются такие атрибуты, как content_type (формат данных) и delivery_mode (требование к сохранению на диск, о чем мы поговорим в главе про надежность).

Шаг 2. Транспортная магистраль: TCP-соединения и Каналы

Сформированное сообщение нужно доставить по сети. RabbitMQ работает поверх протокола TCP. Однако установка нового TCP-соединения (TCP-handshake) — это долгий и ресурсоемкий процесс как для приложения, так и для операционной системы брокера.

Представьте высоконагруженный веб-сервер, который обрабатывает тысячи запросов в секунду. Если каждый поток будет открывать свое TCP-соединение к RabbitMQ, мы мгновенно исчерпаем лимиты сети. Создатели протокола AMQP решили эту проблему элегантно, внедрив AMQP Channels (Каналы).

> AMQP Channel — это виртуальное (логическое) соединение внутри одного физического TCP-соединения.

!Мультиплексирование AMQP-каналов

Приложение открывает ровно одно тяжеловесное TCP-соединение с брокером. Затем каждый рабочий поток приложения открывает внутри этого соединения свой собственный легковесный Канал.

С точки зрения математики лимитов, в одном TCP-соединении может быть открыто каналов, где — количество логических сессий. Это позволяет мультиплексировать трафик: сообщения от разных потоков идут по одной «трубе», но изолированы друг от друга на уровне протокола.

Шаг 3. Прибытие в Точку обмена (Exchange)

Сообщение пересекает сеть по своему Каналу и попадает в память брокера. Первое, с чем оно сталкивается — это Exchange.

Exchange не имеет физического хранилища. Это алгоритм, бессерверный маршрутизатор. Когда сообщение поступает в Exchange, происходит следующий процесс:

Exchange извлекает Routing Key из свойств сообщения.

Exchange обращается к внутренней таблице маршрутизации (списку Bindings).

Происходит сопоставление (мэтчинг): подходит ли Routing Key под условия конкретных привязок.

!Жизненный цикл сообщения

Шаг 4. Клонирование и физическое размещение

Допустим, Exchange нашел три подходящие очереди (Bindings совпали). Что происходит дальше? Копирует ли RabbitMQ тело сообщения (Payload) три раза?

Это популярный вопрос на System Design интервью. Ответ: нет. RabbitMQ крайне бережно относится к оперативной памяти. Если одно сообщение должно попасть в 10 разных очередей, брокер сохранит Payload в памяти ровно один раз. В сами физические очереди будут помещены лишь легковесные ссылки (указатели) на это сообщение.

Сообщение будет физически удалено из памяти брокера только тогда, когда все 10 очередей подтвердят, что их Consumers успешно обработали данные (или когда сообщение будет удалено по истечению срока жизни).

Шаг 5. Тупик: что если пути нет?

Вернемся к парадоксу из начала статьи. Что происходит, если Exchange проверил все Bindings, и ни одна очередь не подошла под Routing Key?

По умолчанию в парадигме AMQP такое сообщение считается «неинтересным» системе. Раз никто не создал очередь и не настроил Binding для таких данных, значит, они никому не нужны. Брокер просто уничтожает (drop) сообщение.

Для многих бизнес-процессов (например, сбор метрик) это идеальное поведение. Но что, если мы отправляем финансовую транзакцию и потеря сообщения недопустима?

Для этого на этапе Шага 1 (упаковка) Producer может выставить специальный флаг — mandatory.

| Поведение брокера | Без флага mandatory (По умолчанию) | С флагом mandatory | | :--- | :--- | :--- | | Очередь найдена | Сообщение маршрутизируется в очередь | Сообщение маршрутизируется в очередь | | Очередь НЕ найдена | Сообщение безвозвратно удаляется (drop) | Сообщение возвращается обратно Producer-у по тому же Каналу с ошибкой basic.return |

Использование флага mandatory заставляет Producer-а реализовывать логику обработки возвратов (асинхронных callback-ов), что усложняет код, но гарантирует, что данные не исчезнут бесследно из-за ошибки в топологии маршрутизации.

Теперь, понимая хронологию движения байтов, мы готовы погрузиться в сердце маршрутизации — алгоритмы работы самих Точек обмена (Exchanges).

Точки обмена (Exchanges): типы, логика работы и алгоритмы фильтрации

Представьте, что вы — диспетчер крупного логистического центра. Иногда вам нужно передать посылку строго определенному курьеру. Иногда — сделать громкое объявление по громкоговорителю для всех сотрудников смены. А порой — найти только тех водителей, чьи маршруты сегодня проходят через северные районы города. Если бы у вас был только один жесткий алгоритм работы, логистика бы встала.

В RabbitMQ роль такого диспетчера играет Exchange (точка обмена). Поскольку сценарии маршрутизации сообщений кардинально различаются, создатели протокола AMQP заложили в него не один, а несколько встроенных алгоритмов фильтрации.

Алгоритм маршрутизации как стратегия

Из предыдущих материалов мы знаем базовую формулу: Producer отправляет сообщение в Exchange, прикрепляя к нему Routing Key (ключ маршрутизации), а Exchange перенаправляет его в Queue (очередь) на основе Binding (привязки).

Но как именно Exchange принимает решение?

Тип точки обмена — это, по сути, конкретная реализация интерфейса фильтрации. Каждый раз, когда сообщение поступает в брокер, Exchange берет метаданные сообщения (Routing Key или заголовки) и сравнивает их с правилами привязки (Binding) для каждой известной ему очереди.

Разница между типами заключается лишь в ответе на один вопрос: «По какому правилу мы сравниваем привязку и сообщение?».

«Большая четверка»: встроенные типы Exchange

В RabbitMQ «из коробки» поставляются четыре основных типа точек обмена. Они покрывают 99% архитектурных задач в распределенных системах.

| Тип Exchange | Логика фильтрации | Аналогия из жизни | Скорость работы | |---|---|---|---| | Direct | Строгое совпадение. Routing Key сообщения должен символ в символ совпадать с ключом привязки. | Письмо с точным почтовым адресом и номером квартиры. | Очень высокая () | | Fanout | Широковещание. Игнорирует Routing Key и копирует сообщение во все привязанные к нему очереди. | Объявление по громкоговорителю на вокзале. | Максимальная | | Topic | Сопоставление по шаблону. Позволяет использовать маски (звездочки и решетки) для гибкой фильтрации. | Подписка на новости: «вспомогательные службы, любые районы». | Высокая (требует парсинга) | | Headers | Маршрутизация по key: value заголовкам сообщения, игнорируя Routing Key. | Таможенная декларация со множеством атрибутов (вес, хрупкость, класс опасности). | Средняя (анализ словаря) |

> Тип Exchange задается в момент его создания (декларации) и не может быть изменен в дальнейшем. Если вам нужно поменять логику маршрутизации, старый Exchange придется удалить и создать новый (либо создать новый параллельно и переключить потоки данных).

!Сравнение четырех типов маршрутизации в RabbitMQ

Иллюзия прямой отправки: Default Exchange

Многие разработчики, впервые открывая документацию или туториалы по RabbitMQ, сталкиваются с парадоксом. В коде они видят команду вроде basicPublish("", "my_queue", message), которая, кажется, отправляет сообщение напрямую в очередь my_queue.

Но мы твердо знаем: в AMQP Producer не может писать напрямую в очередь. Как это работает?

Секрет кроется в механизме Default Exchange (Точка обмена по умолчанию). Это предварительно объявленный брокером Exchange типа Direct, который не имеет имени (его имя — пустая строка "").

Брокер RabbitMQ автоматически применяет к нему два скрытых правила:

Вы не можете удалить Default Exchange или отвязать от него очереди.

Каждая новая очередь, которую вы создаете в брокере, автоматически привязывается к этому безымянному Exchange. Причем в качестве ключа привязки (Binding Key) используется само имя очереди.

Именно поэтому, отправляя сообщение в пустой Exchange "" с Routing Key my_queue, сообщение попадает в очередь my_queue. Брокер просто использует алгоритм точного совпадения (Direct). Это синтаксический сахар, созданный для того, чтобы упростить реализацию простейших задач (например, паттерна Worker Queue), скрыв от новичков сложность AMQP-топологии.

Производительность и выбор

Поскольку каждый тип Exchange использует разную математику для вычисления маршрута, их производительность отличается:

* Fanout работает быстрее всех. Ему не нужно читать ключи или заголовки — он просто итерируется по списку привязанных очередей и передает им ссылки на сообщение. * Direct работает за константное время (где обозначает асимптотическую сложность алгоритма), так как использует хеш-таблицы для мгновенного поиска точного совпадения строки. * Topic тратит дополнительные такты процессора на разбор регулярных выражений и масок. * Headers требует извлечения словаря метаданных и попарного сравнения ключей и значений, что делает его самым ресурсоемким.

Понимание этой разницы критично при System Design проектировании. Если вам нужно просто раскидать задачи по воркерам, нет смысла использовать Topic без масок — Direct справится с этим эффективнее.

Теперь, когда мы видим картину целиком и понимаем, как брокер выбирает алгоритм, пришло время разобрать каждую из этих стратегий под микроскопом.

Direct Exchange: точная маршрутизация по Routing Key

Представьте биллинговую систему, которая генерирует тысячи событий в секунду: успешные списания, отклоненные карты, системные ошибки. Если отправить все эти события в единую трубу, сервису отправки чеков придется скачивать и отбрасывать логи об ошибках базы данных, впустую тратя ресурсы сети и процессора. Нам нужен строгий фильтр: «если событие X — отправь его только в очередь Y». Именно эту задачу решает самый предсказуемый и быстрый тип обменника в RabbitMQ.

Direct Exchange работает по принципу абсолютного совпадения. Это жесткая, детерминированная маршрутизация, не допускающая разночтений.

Механика абсолютного совпадения

В предыдущих главах мы установили, что Producer прикрепляет к сообщению метаданные — Routing Key, а брокер использует Binding для связи обменника с очередью. Чтобы понять Direct Exchange, нам нужно ввести важное различие в терминологии: ключ, с которым сообщение отправляется, и ключ, с которым очередь привязывается к обменнику.

Правило маршрутизации Direct Exchange описывается простейшим условием:

Где: * — Routing Key (ключ маршрутизации), строка, которую Producer прикрепил к сообщению. * — Binding Key (ключ привязки), строка, указанная при создании связи между Exchange и Queue.

Брокер берет и посимвольно сравнивает его со всеми , зарегистрированными в данном обменнике. Никаких регулярных выражений, никаких масок. Если строка payment.success отличается от payment_success хотя бы одним символом — сообщение в очередь не попадет. Благодаря такой простоте, Direct Exchange работает с асимптотической сложностью — брокер просто ищет ключ в хэш-таблице, что делает этот тип маршрутизации невероятно быстрым.

!Схема маршрутизации Direct Exchange

Гибкость через множественные привязки

Строгость правила не означает, что архитектура должна быть примитивной. Вся мощь Direct Exchange раскрывается в том, как мы комбинируем привязки.

Очередь не обязана иметь только один Binding Key. Мы можем привязать одну и ту же очередь к одному Exchange несколько раз с разными ключами.

| Сценарий | Настройка Bindings | Результат | | :--- | :--- | :--- | | Узкая специализация | Очередь receipts привязана только с ключом payment.success. | Очередь получает только успешные платежи. Игнорирует ошибки. | | Агрегация | Очередь audit_log привязана трижды: с ключами payment.success, payment.failed, payment.refund. | Очередь собирает все финансовые операции, но игнорирует системные логи вроде db.timeout. |

В случае агрегации брокер проверяет Routing Key входящего сообщения. Если он совпадает хотя бы с одним из ключей привязки очереди, сообщение будет доставлено.

Разветвление потока (Дублирование)

Что произойдет, если две разные очереди привязать к Direct Exchange с одинаковым Binding Key?

Допустим, у нас есть ключ payment.success. Мы привязываем к нему очередь receipts (отправка чеков) и очередь analytics (пересчет конверсии). Когда Producer отправляет сообщение с Routing Key payment.success, брокер находит два совпадения.

В этот момент RabbitMQ мультиплицирует сообщение (как мы помним из второй главы — копирует ссылки в памяти, а не сам Payload) и доставляет его в обе очереди. Таким образом, Direct Exchange позволяет реализовать паттерн Publish/Subscribe для конкретных, точечных событий. Оба сервиса получат свою копию данных и смогут обрабатывать их независимо.

Балансировка нагрузки: паттерн Competing Consumers

Мы разобрались, как размножить сообщение по разным очередям. Но что, если сообщений в одной очереди стало слишком много? Если в очередь receipts падает 1000 платежей в секунду, один Consumer (сервис генерации PDF) с такой нагрузкой не справится.

Здесь вступает в игру паттерн Competing Consumers (Конкурирующие потребители). Мы можем запустить 5 экземпляров сервиса генерации чеков и подключить их все к одной очереди receipts.

Важно понимать фундаментальное отличие от дублирования сообщений между очередями: если несколько Consumer слушают одну и ту же очередь, сообщение достанется только одному из них. RabbitMQ по умолчанию использует алгоритм Round-Robin (карусель) для распределения сообщений.

!Round-Robin распределение сообщений

Первое сообщение уйдет первому Consumer, второе — второму, третье — третьему, а четвертое — снова первому. Это позволяет линейно масштабировать производительность системы: не справляетесь с потоком — просто запустите еще несколько контейнеров с Consumer, и RabbitMQ автоматически размажет нагрузку между ними.

Практический кейс: Система логирования

Сведем все концепции воедино на классическом примере — маршрутизации логов.

У нас есть три уровня критичности логов, которые Producer отправляет с соответствующими Routing Key: info, warning, error. Мы создаем точку обмена logs_direct и две очереди:

disk_archive_queue — должна сохранять абсолютно все логи на жесткий диск.

alert_queue — должна будить дежурного инженера только при критических сбоях.

Настройка привязок: * disk_archive_queue привязывается к logs_direct три раза: с ключами info, warning и error. * alert_queue привязывается к logs_direct только один раз: с ключом error.

Как это работает в динамике:

Producer отправляет лог с ключом info. Брокер видит совпадение только для disk_archive_queue. Сообщение уходит на диск. Дежурный спит.

Producer отправляет лог с ключом error. Брокер находит совпадения для обеих очередей. Сообщение дублируется: копия ложится на диск для истории, а вторая копия попадает в alert_queue, где ее подхватывает один из конкурирующих Consumer (по алгоритму Round-Robin) и отправляет SMS инженеру.

Direct Exchange дает нам абсолютный контроль над тем, куда попадет каждое конкретное сообщение. Однако, если завтра мы добавим новый уровень логов critical, нам придется вручную добавлять новые привязки для disk_archive_queue. О том, как маршрутизировать данные по шаблонам и маскам, избегая ручного дублирования конфигураций, мы поговорим при разборе Topic Exchange.

Fanout Exchange: реализация паттерна Publish/Subscribe без фильтров

Представьте, что вам нужно отправить одно и то же сообщение сотне разных микросервисов. Если использовать уже знакомый нам Direct Exchange, брокеру придется прочитать ключ маршрутизации, сравнить его со списком из ста привязок и только потом скопировать ссылки в очереди. А что, если мы заранее знаем, что сообщение нужно доставить абсолютно всем? Тратить процессорное время на проверку строк становится бессмысленно. Для таких задач в RabbitMQ существует тип обменника, который работает по принципу рупора.

Мегафон для брокера: как работает Fanout

Fanout Exchange (от англ. fan out — разворачивать веером, распространять) — это самый простой и прямолинейный тип точки обмена. Его главная особенность заключается в том, что он полностью игнорирует Routing Key.

Когда Producer отправляет сообщение в Fanout Exchange, брокер даже не заглядывает в метаданные сообщения. Алгоритм его работы сводится к одному элементарному действию: взять пришедшее сообщение и безусловно разослать его копии (точнее, ссылки на него) во все очереди, которые к нему привязаны.

!Схема работы Fanout Exchange

При создании привязки (Binding) к Fanout Exchange указывать Binding Key не нужно. Даже если вы передадите какую-то строку при настройке, брокер просто проигнорирует её.

> Fanout Exchange — это слепой распределитель. Ему неважно, о чем сообщение и кому оно предназначалось. Если очередь привязана к обменнику, она получит копию.

Идеальный Publish/Subscribe

Именно Fanout Exchange является классической реализацией архитектурного паттерна Publish/Subscribe (Pub/Sub) в экосистеме AMQP.

В предыдущей главе мы разбирали паттерн Competing Consumers, где несколько обработчиков слушали одну очередь, и каждое сообщение доставалось только одному из них (балансировка Round-Robin).

В модели Pub/Sub логика принципиально иная: одно событие должно быть обработано несколькими независимыми подсистемами, каждая из которых делает свою уникальную работу. Для этого каждая подсистема создает свою собственную очередь и привязывает её к общему Fanout Exchange.

| Характеристика | Competing Consumers (Direct + 1 очередь) | Publish/Subscribe (Fanout + N очередей) | |---|---|---| | Цель | Распараллелить тяжелую задачу | Уведомить разные системы об одном факте | | Количество копий | Сообщение обрабатывается 1 раз | Сообщение обрабатывается N раз (каждым сервисом) | | Топология | 1 очередь множество воркеров | Множество очередей по одному воркеру на каждую | | Пример | Пул серверов для ресайза картинок | Рассылка события user.registered в разные отделы |

Анатомия производительности

Fanout — это самый быстрый тип обменника в RabbitMQ.

В Direct Exchange время маршрутизации зависит от необходимости вычислить хэш от Routing Key и найти совпадения. Если усложнить логику до Topic Exchange (о котором мы поговорим в следующей главе), брокеру придется применять регулярные выражения и маски, что требует еще больше ресурсов.

Для Fanout Exchange вычислительная сложность принятия решения о маршрутизации составляет . Брокеру не нужно читать заголовок и сравнивать строки. Время, затрачиваемое на логику маршрутизации, описывается как , где — константа, необходимая лишь для того, чтобы запустить цикл по заранее известному списку привязанных очередей.

Если ваша система генерирует десятки тысяч событий в секунду, и эти события нужно транслировать множеству подписчиков, Fanout обеспечит минимальный overhead (накладные расходы) на стороне RabbitMQ.

Практический кейс: оформление заказа

Рассмотрим классическую микросервисную архитектуру e-commerce платформы. Пользователь нажимает кнопку «Оплатить». Сервис заказов (Producer) формирует событие order.created и отправляет его в Fanout Exchange с именем orders.broadcast.

На момент запуска стартапа у нас есть три сервиса, которым нужно знать о новых заказах. Каждый из них создает свою очередь и привязывает её к orders.broadcast:

Складской сервис (очередь inventory_queue) — резервирует товар на полке.

Биллинг (очередь billing_queue) — инициирует списание денег с карты.

Сервис уведомлений (очередь notification_queue) — отправляет клиенту SMS "Ваш заказ принят".

Спустя полгода бизнес решает внедрить систему аналитики и систему обнаружения мошенничества (Anti-Fraud). Как внедрить их в архитектуру?

!Динамическое добавление подписчиков в Fanout

В синхронной архитектуре (REST) нам пришлось бы переписывать код Сервиса заказов, добавляя туда новые HTTP-вызовы. В модели Pub/Sub на базе Fanout мы вообще не трогаем Producer. Новые микросервисы просто создают свои очереди (analytics_queue и fraud_queue) и привязывают их к существующему Fanout Exchange. Со следующей секунды они начинают получать копии всех новых заказов. Это триумф пространственной и временной развязки, о которой мы говорили в начале курса.

Fanout против Direct с одинаковыми ключами

Частый вопрос на System Design интервью: «Мы знаем, что в Direct Exchange можно привязать несколько очередей с одним и тем же Binding Key, и сообщение сдублируется в них обе. Зачем тогда нужен Fanout?»

Действительно, топология: Direct Exchange Queue A (key="event") и Queue B (key="event") даст тот же результат, что и Fanout, если отправлять сообщения с Routing Key = "event".

Однако использование Fanout предпочтительнее по двум причинам:

Семантика архитектуры: Глядя на топологию RabbitMQ, другой инженер сразу поймет ваши намерения. Тип Fanout явно говорит: «Здесь происходит широковещательная рассылка, фильтрации нет».

Производительность: Как мы выяснили выше, Fanout не тратит такты процессора на сравнение строк. Даже если ключи идентичны, Direct Exchange обязан честно выполнить операцию сравнения для каждой привязки.

Fanout идеален, когда событие безусловно касается всех подписчиков. Но что делать, если сервису уведомлений нужны все события, а сервису аналитики — только события из европейского региона? Здесь прямолинейность Fanout становится минусом, и нам потребуется более умный инструмент.