Подтвердить что ты не робот

RabbitMQ: обмены, очереди и привязки - кто что настраивает?

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

В принципе, у меня есть три сценария в моем приложении.

Сценарий 1: один издатель, несколько рабочих процессов

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

  • Обмен: 1 обмен с типом 'direct'
  • Очередь: 1 очередь
  • Связывание: очередь привязана к обмену

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

Все должно быть долговечным.

Итак, кто что делает? По-моему:

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

Right?

Сценарий 2: один издатель, несколько подписчиков, изменчивые сообщения

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

  • Обмен: 1 обмен с типом 'fanout'
  • Очередь: n очередей, по одному для каждого пользователя
  • Связывание: каждая очередь должна быть привязана к обмену

Итак, кто что делает? По-моему:

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

Right?

Сценарий 3: один издатель, несколько подписчиков, прочные сообщения

В основном то же самое, что и сценарий 2, но сообщения не должны быть потеряны, если потребитель переходит в автономный режим. По-моему, это ничего не меняет - правильно?

4b9b3361

ОТВЕТЫ

Ответ 1

Я думаю, что вы говорите правильно, за исключением сценария 3.

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

Все остальное мне кажется правильным.

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

Ответ 2

В этой статье перечислены различные подходы к созданию производителем и/или потребителем обменов, очередей и привязок.

Ответ 3

У меня нет 50 репутации, чтобы комментировать, поэтому я опубликую ответ.

"Система должна быть автономной без необходимости внешнего администратора" - как вы это понимаете?

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

Случай 1

Кто-то должен будет установить его заранее, насколько я могу судить. Этот парень таинственный "внешний администратор". Он/она будет иметь руководство по установке, поставляемое вами как часть вашего пакета, или очень хорошо продуманный, не требующий пояснений мастер установки будет направлять его/ее клики. За кулисами одного из этих кликов ваш установщик сможет настроить брокерские структуры RabbitMQ.

Дело 2

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

Дело 2/б

То же самое без оборудования, вы отправляете образ виртуальной машины. Тем не менее, вы внешний администратор.

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

  1. Часть установщика должна быть хороша при настройке топологии MQ, структуры файловой системы, структуры базы данных, интерфейсных соединений и тому подобного.
  2. Издатель (и) должен хорошо предоставлять данные о качестве для потребителей
  3. Потребитель (и) должны хорошо обрабатывать данные, полученные от издателя (ей)

Это напрашивается на неприятности, если вы все перепутаете.

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