Насколько я понимаю, кластеризация RabbitMQ предназначена для масштабируемости, а не для доступности, но использование зеркальных очередей также обеспечивает доступность, поскольку в случае сбоя этого ведущего устройства обновленное ведомое устройство может быть повышено до ведущего.
Из документации:
Сообщения, опубликованные в очереди, реплицируются на все ведомые устройства. Потребители подключаются к мастеру независимо от того, к какому узлу они подключаются, при этом ведомые устройства отбрасывают сообщения, которые были подтверждены на мастере. Таким образом, зеркальное отображение очереди повышает доступность, но не распределяет нагрузку между узлами (все участвующие узлы выполняют всю работу).
Следовательно, балансировка нагрузки между узлами для данной очереди не имеет смысла, поскольку это всегда будет добавлять дополнительную поездку от узла, с которым связывается, к главному узлу для очереди (если я что-то не понимаю). Следовательно, мы хотели бы всегда иметь возможность знать, какой узел является главным для данной очереди.
Я на самом деле не очень много работал с RabbitMQ, поэтому, возможно, мне просто не хватает этого в документации, но кажется, что нет способа определить IP-адрес мастера зеркальной очереди, если произошел сбой мастера и подчиненное устройство было повышено до владелец. Каждый источник, который я вижу, просто отмечает способность человека установить начальный главный узел, что для меня не очень помогает. Как мне найти IP-адрес главного узла для данной очереди в любое время t?
PS: Также кажется плохим иметь узлы за балансировщиком нагрузки, так как если есть какой-то сетевой раздел (который может возникать даже с узлами в той же локальной сети), то мы потенциально можем столкнуться с узлами, которые не могут связываться с master для очереди ИЛИ, что еще хуже, может быть разделенный мозг, который мы будем развивать, если хотите.