Эффективные стратегии привязки RabbitMQ для маршрутизации сообщений

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

Самый полезный способ думать о стратегиях привязки RabbitMQ — не «какой тип обменника лучше?». Это «какое обещание я даю о доставке сообщения?». Событие выставления счета, журнал аудита, инвалидация кэша и повторное сообщение имеют разные потребности в маршрутизации. Привязка должна делать это намерение очевидным.

Начните с формы события

Ключи маршрутизации работают лучше всего, когда они описывают стабильные факты о сообщении, а не временные детали реализации. Ключ типа orders.created вероятно переживет несколько версий вашего приложения. Ключ типа worker-3.fast-path вероятно нет.

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

domain.entity.action
orders.invoice.created
orders.invoice.paid
orders.shipment.failed
users.account.disabled

Потребитель может затем привязаться к orders.invoice.* для событий счетов, orders.# для всех событий домена заказов или #.failed для обработки операционных сбоев. Это гораздо проще для понимания, чем смешивать new_order, invoice.paid и shipping-error на одном обменнике.

Прямые привязки: точные имена для точных задач

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

rabbitmqadmin declare exchange name=orders.events type=direct durable=true
rabbitmqadmin declare queue name=billing.invoice-created durable=true
rabbitmqadmin declare queue name=audit.order-events durable=true

rabbitmqadmin declare binding source=orders.events destination=billing.invoice-created routing_key=invoice.created
rabbitmqadmin declare binding source=orders.events destination=audit.order-events routing_key=invoice.created
rabbitmqadmin declare binding source=orders.events destination=audit.order-events routing_key=invoice.paid

Если сообщение опубликовано с invoice.created, обе очереди получают копию. Если оно опубликовано с shipment.created, ни одна очередь не получает его, если не существует другой привязки. Эта точность и есть суть.

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

Тематические привязки: гибкие подписки без изменения издателей

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

rabbitmqadmin declare exchange name=platform.events type=topic durable=true
rabbitmqadmin declare queue name=fraud.orders durable=true
rabbitmqadmin declare queue name=ops.failures durable=true
rabbitmqadmin declare queue name=analytics.all-events durable=true

rabbitmqadmin declare binding source=platform.events destination=fraud.orders routing_key=orders.payment.*
rabbitmqadmin declare binding source=platform.events destination=ops.failures routing_key=#.failed
rabbitmqadmin declare binding source=platform.events destination=analytics.all-events routing_key=#

Правила подстановочных знаков точны:

• * соответствует ровно одному слову между точками.
• # соответствует нулю или более слов.

Таким образом, orders.*.failed соответствует orders.payment.failed, но не orders.eu.payment.failed. orders.# соответствует orders, orders.created и orders.eu.payment.failed.

Основной риск с тематическими обменниками — случайная чрезмерная подписка. Очередь, привязанная к #, будет получать все, что опубликовано в обменник. Это может быть нормально для аналитических или архивных систем, но это плохой сюрприз для сервиса, который понимает только одну схему сообщений. Делайте широкие привязки редкими и называйте такие очереди честно.

Привязки Fanout: широковещательная рассылка без споров о ключе маршрутизации

Обменник fanout отправляет каждое сообщение во все привязанные очереди и игнорирует ключ маршрутизации. Это делает его отличным для инвалидации кэша, локальных отладочных очередей и уведомлений «каждая подсистема должна это услышать».

rabbitmqadmin declare exchange name=deploy.notifications type=fanout durable=true
rabbitmqadmin declare queue name=slack.deploys durable=true
rabbitmqadmin declare queue name=audit.deploys durable=true

rabbitmqadmin declare binding source=deploy.notifications destination=slack.deploys
rabbitmqadmin declare binding source=deploy.notifications destination=audit.deploys

Не используйте fanout, потому что ключи маршрутизации кажутся неудобными. Если только трем из десяти потребителей нужно сообщение, используйте прямую или тематическую маршрутизацию. Fanout намеренно груб: каждая привязанная очередь получает копию.

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

Обменники заголовков маршрутизируют по заголовкам сообщений вместо ключей маршрутизации. Они могут соответствовать всем заголовкам или любому заголовку, используя аргумент привязки x-match.

import pika

connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()

channel.exchange_declare(exchange='documents', exchange_type='headers', durable=True)
channel.queue_declare(queue='pdf-invoices', durable=True)

channel.queue_bind(
    exchange='documents',
    queue='pdf-invoices',
    arguments={'x-match': 'all', 'format': 'pdf', 'type': 'invoice'}
)

channel.basic_publish(
    exchange='documents',
    routing_key='ignored',
    body=b'...',
    properties=pika.BasicProperties(headers={'format': 'pdf', 'type': 'invoice'})
)

connection.close()

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

Ошибки привязки, которые приводят к реальным инцидентам

Самая распространенная ошибка привязки — несоответствие виртуального хоста. Объекты RabbitMQ живут внутри виртуальных хостов. Обменник с именем orders.events в / — это не тот же объект, что orders.events в prod. Всегда проверяйте с помощью -V или -p при использовании инструментов CLI.

rabbitmqctl -p prod list_bindings source_name destination_name routing_key arguments

Следующая ошибка — предположение, что прямой обменник ведет себя как тематический. Прямая привязка orders.* соответствует только буквальному ключу orders.*. Она не соответствует orders.created. Если нужны подстановочные знаки, тип обменника должен быть topic.

Еще одна распространенная ошибка — привязка очереди к обменнику повторных попыток с тем же ключом маршрутизации, который немедленно отправляет сообщение обратно в себя. Это может создать быстрый цикл повторных попыток. Для повторных попыток сделайте путь явным: активная очередь -> обменник повторных попыток -> очередь задержки -> исходный обменник, с парковочной очередью после последней попытки.

Наконец, следите за дублирующимися привязками, созданными автоматизацией. RabbitMQ обрабатывает дублирующиеся привязки с одинаковыми свойствами идемпотентно, но почти дублирующиеся все еще различны. orders.created и order.created могут существовать рядом месяцами, пока кто-то не заметит, что половина сообщений уходит не в тот сервис.

Простой контрольный список для проверки

Перед отправкой изменения маршрутизации я люблю ответить на эти вопросы:

• Какой обменник получает публикацию?
• Какой точный ключ маршрутизации или заголовки отправит производитель?
• Какие очереди должны получить одну копию?
• Какие очереди не должны ее получать?
• Что произойдет, если ни одна привязка не совпадет?
• Есть ли альтернативный обменник или обработка возврата издателя для нерутируемых сообщений?
• Являются ли привязки повторных попыток и недоставленных сообщений однонаправленными или могут зацикливаться?

Затем проверьте развернутую топологию:

rabbitmqctl -p prod list_exchanges name type durable arguments
rabbitmqctl -p prod list_queues name durable arguments
rabbitmqctl -p prod list_bindings source_name source_kind destination_name destination_kind routing_key arguments

Хорошие стратегии привязки RabbitMQ обычно скучны. Имена предсказуемы, подстановочные знаки намеренны, а путь отказа виден. Это именно то, что нужно, когда производитель развертывается в полночь, а граф очередей должен объяснить себя без совещания.