В RabbitMQ, который дороже, несколько очередей на обмен, или несколько обменов и меньше очередей на каждого?

Итак, мы решили пойти с RabbitMQ в качестве шины сообщений/событий в нашей миграции на архитектуру микросервисов, но мы не смогли найти однозначного ответа на вопрос о том, как лучше всего поставить наши очереди, у нас есть два варианта: пойдите с:

Один из основных обменов, который будет обмена Fanout, который, в свою очередь, будет отправлять сообщения в основную очередь для ведения журнала и других целей и другого подзаголовка, который будет обмениваться темами и направлять сообщения в каждую желаемую очередь используя ключ маршрутизации сообщения. Мы ожидаем, что количество очередей за суб-биржей будет каким-то большим количеством. Это можно объяснить этим графиком:
Один основной обмен, который будет обменом Темами, с еще одной основной очередью, привязанной к этому обмену, с использованием ключа маршрутизации "#". Этот основной обмен также будет обрабатывать основную маршрутизацию на другие суб-обмены, поэтому ключи маршрутизации могут быть "соглашениями. #", "Присваиваниями. #", "Сообщениями. #", Которые затем используются для привязки нескольких подсегментов к темам, каждый из которых будет обрабатывать вспомогательную маршрутизацию, поэтому один дополнительный обмен может обрабатывать все "назначения", а очереди, связанные с этим обменом, могут быть связаны с помощью маршрутизации ключей, таких как "assignments.accepted", "assignments.deleted"... В этом сценарии мы чувствуем, что огромное количество очередей будет меньше за обмен, они будут как-то распределены между биржами. Итак, какой из этих сценариев мог бы быть лучшим подходом? Быстрее на RabbitMQ, меньше накладных расходов.

Принимая во внимание, что все очереди, обмены и привязки будут выполняться "на лету" из службы, которая будет либо опубликована, либо подписана.

Ответ 1

Я собираюсь сначала обобщить то, что, на ваш взгляд, ваш вопрос, так как я уверен, что он похоронил где-то на вашем посту.

Желательно иметь очередь трассировщика/регистрации в дополнение к серии заданий для конкретной обработки сообщений. Какая топология обмена лучше всего подходит для этого сценария?

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

Что делать?

Важно помнить, что в RabbitMQ очереди, которые потребляют ресурсы брокера. Обмены просто соединяют очереди с издателями. Обмен - это средство для конца, а очередь - это сам конец.

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

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

Ответ 2

Вы можете найти некоторые объяснения в этой теме: RabbitMQ Обмен темами: 1 Обмен против множества обменов

Я использую RabbitMQ очень похоже на то, что вы показали в случае 2, поскольку я обнаружил те же преимущества, что описаны в этой статье: https://skillachie.com/2014/06/27/rabbitmq-exchange-to-exchange-bindings-ampq/

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

Считается, что привязки обмена к обмену очень легкие и в результате помогают повысить производительность *

Основанный на моем собственном опыте обмена с обменом, случай 2 хорош, и он позволяет очень быстро создавать/изменять топологии потока сообщений.