При использовании RabbitMQ для отправки сообщений у вас в основном есть обмены, очереди и привязки. Я понял их идею и то, как они соотносятся друг с другом, но я не совсем уверен, кто что делает.
В принципе, у меня есть три сценария в моем приложении.
То, что я хочу достичь, - это один компонент, который отправляет сообщения в очередь, и должно быть несколько рабочих процессов, которые обрабатывают элементы в этой очереди. Мне это кажется очень легким. Настройка выполняется следующим образом:
Всякий раз, когда сообщение отправляется на обмен, оно доставляется в очередь, а рабочие процессы выполняют свои задачи.
Все должно быть долговечным.
Итак, кто что делает? По-моему:
Right?
Второй сценарий совсем другой. В основном это сценарий pub/sub, где каждое сообщение отправляется каждому слушающему клиенту. Если клиент переходит в автономный режим, он больше не получает сообщений, и он не хранится нигде для него. Это означает следующую настройку:
Итак, кто что делает? По-моему:
Right?
В основном то же самое, что и сценарий 2, но сообщения не должны быть потеряны, если потребитель переходит в автономный режим. По-моему, это ничего не меняет - правильно?
Я думаю, что вы говорите правильно, за исключением сценария 3.
Если сообщения не должны быть потеряны, если потребитель отключен, тогда вам потребуются длительные очереди, а очереди не могут быть автообновлены.
Все остальное мне кажется правильным.
В случае сценария 2 вы также можете позволить RabbitMQ автоматически генерировать имена очереди для вас, а затем позволить этим очередям автоматически удаляться после того, как потребитель отключится.
В этой статье перечислены различные подходы к созданию производителем и/или потребителем обменов, очередей и привязок.
У меня нет 50 репутации, чтобы комментировать, поэтому я опубликую ответ.
"Система должна быть автономной без необходимости внешнего администратора" - как вы это понимаете?
Я боюсь, что ваше программное обеспечение захочет работать на некотором оборудовании. Но как?
Кто-то должен будет установить его заранее, насколько я могу судить. Этот парень таинственный "внешний администратор". Он/она будет иметь руководство по установке, поставляемое вами как часть вашего пакета, или очень хорошо продуманный, не требующий пояснений мастер установки будет направлять его/ее клики. За кулисами одного из этих кликов ваш установщик сможет настроить брокерские структуры RabbitMQ.
Вы поставляете свою систему как устройство "под ключ" - вы продаете оборудование вместе с ним и отправляете все настроенное. В этом случае вы являетесь внешним администратором, и в процессе настройки вы настраиваете структуры брокера RabbitMQ. К тому времени, когда конечный пользователь запускает вашего издателя и потребителя, все готово.
То же самое без оборудования, вы отправляете образ виртуальной машины. Тем не менее, вы внешний администратор.
Разделение проблем дает вам большой потенциал для будущего масштабирования и улучшения/реструктуризации вашей системы, упрощения обслуживания версий для разных клиентов.
Это напрашивается на неприятности, если вы все перепутаете.
Иными словами: некоторые рассуждения уже заставили вас создать компоненты издателя и потребителя в вашей системе вместо того, чтобы полностью обрабатывать поток данных в одном и том же компоненте. Продвиньте те же самые рассуждения немного дальше.