Что такое Headers Exchange в RabbitMQ?

Смотри, Headers Exchange в RabbitMQ — это как самый занудный и придирчивый начальник на районе. Он вообще не смотрит на routing key, который все остальные используют. Ему подавай заголовки, эти пары ключ-значение в свойствах сообщения. Хочешь сложную логику, где надо учесть кучу условий сразу? Вот он твой выбор, ёпта.

Чем он не такой, как все:

Главная фишка: x-match

Когда привязываешь очередь к такому обменнику, ты должен указать x-match. Это как сказать ему: «Слушай, а как ты будешь сравнивать?»

• x-match = all (стоит по умолчанию): Все указанные тобой условия должны совпасть. Это логическое «И». Жёстко, зато точно.
• x-match = any: Достаточно совпадения хотя бы по одному пункту. Логическое «ИЛИ». Попроще, поживее.

Пример на C#, чтобы было понятно, о чём речь:

using RabbitMQ.Client;
using System.Text;
using System.Text.Json;

// Подключаемся, как обычно
var factory = new ConnectionFactory { HostName = "localhost" };
using var connection = factory.CreateConnection();
using var channel = connection.CreateModel();

// Объявляем самого придирчивого обменника
channel.ExchangeDeclare(exchange: "notifications_headers", type: ExchangeType.Headers, durable: true);

// Теперь создаём очереди и говорим им, на какие заголовки подписываться

// Очередь для ВАЖНЫХ JSON-уведомлений. Будет оч-чень привередливой.
channel.QueueDeclare("queue_critical_json", durable: true, exclusive: false, autoDelete: false);
var criticalBindArgs = new Dictionary<string, object>
{
    { "format", "json" },
    { "priority", "high" },
    { "x-match", "all" } // Важно! Должны совпасть ОБА условия: И format=json, И priority=high.
};
channel.QueueBind(queue: "queue_critical_json", exchange: "notifications_headers", routingKey: "", arguments: criticalBindArgs);

// Очередь для общих уведомлений. Попроще, жадная до всего.
channel.QueueDeclare("queue_general", durable: true, exclusive: false, autoDelete: false);
var generalBindArgs = new Dictionary<string, object>
{
    { "format", "xml" },
    { "tag", "legacy" },
    { "x-match", "any" } // А тут достаточно ЛЮБОГО из условий: format=xml ИЛИ tag=legacy.
};
channel.QueueBind(queue: "queue_general", exchange: "notifications_headers", routingKey: "", arguments: generalBindArgs);

// А теперь публикуем сообщение
var message = new { Text = "Важное событие!" };
var body = Encoding.UTF8.GetBytes(JsonSerializer.Serialize(message));

var properties = channel.CreateBasicProperties();
properties.Persistent = true;
// Вот наши волшебные заголовки
properties.Headers = new Dictionary<string, object>
{
    { "format", "json" },
    { "priority", "high" },
    { "source", "api" }
};

// Что произойдёт?
// Сообщение полетит ТОЛЬКО в "queue_critical_json", потому что у него format=json И priority=high. Оба условия сошлись!
// В "queue_general" оно не попадёт, потому что у него нет ни format=xml, ни tag=legacy. Не повезло.
channel.BasicPublish(exchange: "notifications_headers",
                     routingKey: "", // Ключ маршрутизации тут вообще не важен, можно пустой
                     basicProperties: properties,
                     body: body);

Когда его использовать, а когда нет?

Используй, когда:

• Логика фильтрации — просто пиздец сложная. Нужно учесть кучу независимых параметров: версия API=2, регион=EU, тип клиента=premium.
• Маршрутизация идёт по свойствам, а не по теме. Не лезет в иерархию Topic Exchange.
• Клиенты хотят гибко настраивать подписку. «Дайте мне всё, где format=json И priority=high, но если есть tag=test, то нахуй не надо».

Не используй, когда:

• Нужна просто скорость. Маршрутизация по заголовкам — это сравнение хэш-таблиц, оно тяжелее, чем просто матчинг по строке ключа. Для простых и быстрых сценариев бери Direct или Topic.
• Логика простая как три копейки. Не надо тащить сюда слона, если можно обойтись мухой.

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