Headers и альтернативный exchange

Headers exchange не читает routing key вовсе: он сравнивает заголовки публикации с аргументами привязки. Издатель кладёт атрибуты в поле Headers типа amqp.Table: amqp.Publishing{Headers: amqp.Table{"format": "pdf", "type": "report"}}. Привязка передаёт свои условия аргументами QueueBind — таблицей с обязательным ключом x-match: amqp.Table{"x-match": "all", "format": "pdf", "type": "report"}. Режим x-match решает, считать ли совпадением все заголовки или хотя бы один; это единственный спецключ в таблице, остальные пары — ваши условия. Значения сравниваются с учётом типа: строка "2" и число 2 — разные вещи, и это ловит при миграциях форматов. Обменник объявляется знакомо: ch.ExchangeDeclare("documents", "headers", true, false, false, false, nil) — durable, идемпотентность и PRECONDITION_FAILED при смене типа работают как у direct из одиннадцатого урока, а в management UI тестовая публикация заполняет заголовки таблицей в той же форме.

Логика x-match — два правила, и их полезно проговорить на примерах. Режим all требует совпадения всех заголовков из привязки: условие x-match all с format pdf и type report пропустит только сообщения, у которых совпали оба; лишние заголовки публикации роли не играют — важен лишь набор, перечисленный в привязке. Режим any требует совпадения хотя бы одного: та же привязка в режиме any возьмёт и «pdf», и «report» по отдельности. Any с единственным заголовком превращается в фильтр по одному признаку — так делают избирательные подписки без topic-словаря. Масок у заголовков нет: совпадение точное, без звёздочек и префиксов; если нужна иерархия значений — это работа для topic из тринадцатого урока. Комбинации получаются выразительными: несколько привязок на одну очередь с разными условиями собирают сложные выборки, а издатель просто публикует заголовки и не знает про фильтры ничего.

Alternate exchange — настройка основного обменника: всё, что не нашло очередь, брокер переправляет в запасной. Задаётся аргументом при объявлении: ch.ExchangeDeclare("orders", "direct", true, false, false, false, amqp.Table{"alternate-exchange": "orders.unrouted"}) — и сам запасной объявляется раньше, иначе объявление основного упадёт со ссылкой на несуществующую сущность. Дальше механика простая: публикация с ключом, к которому нет привязок, уходит в orders.unrouted; там обычно стоит fanout и одна очередь-ловушка. Это серверное решение проблемы из warn-врезки одиннадцатого урока: не каждый издатель ловит возвраты через mandatory, а брокер централизованно складывает промахи в место, которое вы контролируете. Правила строгие: сообщение, переправленное в запасной и снова не нашедшее очередь, уничтожается — каскада из alternate в alternate не будет; и NotifyReturn не сработает, если переправка состоялась: брокер считает доставку удавшейся.

Ловушка без наблюдения бесполезна: очередь промахов должна звучать. Минимум — глубина и возраст в дашборде, как у любой очереди из двадцать второго урока; правильнее — алерт на каждое сообщение: в здоровой топологии промахов не бывает, и каждая поимка — инцидент с телом, которое видно в management UI и можно переопубликовать после починки. Связка с обязательными возвратами из шестого урока распределяется по уровням: mandatory с NotifyReturn возвращает недоставленное конкретному издателю — вариант там, где публикация и обработка возврата в одних руках; alternate exchange работает централизованно и не требует дисциплины от каждого автора публикаций. DLX из шестнадцатого урока решает зеркальную задачу — куда уходит сообщение, которое потребитель не осилил, — и механически похож: аргумент при объявлении плюс обменник-приёмник. Разница в направлении: alternate ловит недоставленное до потребителя, dead letter — после. И то и другое настраивают аргументами при объявлении — отсюда и путаница: x-dead-letter-exchange живёт на очереди, alternate-exchange — на обменнике.

Headers exchange — редкий гость в продакшн-схемах, и это надо признать прямо: команды выбирают direct, topic и fanout, а заголовками маршрутизируют единицы. Причины понятны: ключ виден в логах и метриках, выглядит в management UI и на ревью, а заголовки прячутся внутри сообщения; словарь ключей читается, таблица условий — нет. Но есть ситуации, где headers выигрывает честно: атрибутов несколько, часть опциональна, их множество комбинаторно растёт; правила маршрутизации меняются чаще кода; нужна маршрутизация без вынесения служебных данных в ключ, например по версиям форматов. Рабочий критерий: если маршрут описывается одним словом или маской — берите ключ; если требует связки трёх-четырёх флагов с опциями — заголовки перестают быть экзотикой. Alternate exchange — другая история: он не выбирается вместо заголовков, а ставится аргументом на любой обменник любого типа, и в боевых схемах на него стоит смотреть как на обязательную страховку.