NServiceBus RabbitMQ - DirectRoutingTopology против отдельных обменов для каждого типа сообщений

Question

Мы используем NServiceBus поверх MSMQ. Теперь мы переходим к использованию RabbitMQ - нам нужна централизованная очередь, и мы обнаружили, что RabbitMQ наилучшим образом отвечает нашим потребностям.

Преобразовать наш проект было легко, и в RabbitMQ мы заметили, что он создал обмен (и очередь) для каждой конечной точки и типа сообщения в этой конечной точке.

Я прочитал раздел Изменение топологии маршрутизации в http://docs.particular.net/nservicebus/rabbitmq/configuration-api и там написано

Для менее сложных сценариев вы можете использовать DirectRoutingTopology

Что не удалось объяснить в документации, так это параметры, которые определяют решение как complex,

Я искал и не мог найти где-нибудь, что объясняет, что считается сложным, и когда следует DirectRoutingTopology использоваться поверх опции по умолчанию, где используются несколько обменов. Или каковы различия / соображения производительности между каждым подходом.

Кто-нибудь знает?

Answer 1

Дело не в производительности, а в том, чтобы использовать технологию наилучшим образом.

Каждая очередь должна быть единицей работы. Допустим, я отправляю сообщение A, если нужно выполнить 1 единицу работы, то имеет смысл иметь 1 обмен с 1 очередью для обработки сообщений.

Допустим, у вас есть messageB, которому нужно выполнить оба действия X и Y. В этом случае у вас будет 1 обмен, который отправит сообщение в 2 разные очереди (FANOUT Exchange)

Допустим, у вас есть messageC, которому требуется действие X ИЛИ Y для выполнения на основе параметра. В этом случае вы захотите использовать обмен DIRECT с маршрутизацией, указанной в 2 разных очередях (но сообщение будет заканчиваться только в 1 из 2 очередей).

Надеюсь, это имеет смысл.