RabbitMQ, как оптимально публиковать / потреблять сообщения в кластере?

Question

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

Если мы публикуем сообщение по соединениюоткрыт для сервера 1 (s1), но очереди master-locator-node находятся на сервере 2 (s2), сервер должен переместить это сообщение с s1 на s2, верно?

Было бы оптимальным всегда использовать изочереди, которые являются «локальными» для сервера, к которому мы подключены, что означает, что все очереди, которые мы используем по нашему соединению, расположены на этом сервере, не так ли?

Это слишком сложно?Или лучше всегда публиковать и использовать на серверах, где находится очередь?Я ежедневно работаю с сообщениями около 3B, поэтому стараюсь максимально сократить время ожидания и загружать.

Answer 1

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

Если вы не беспокоитесь о потере сообщений, в этом сценарии не требуется кластер.

---

_{ПРИМЕЧАНИЕ: команда RabbitMQ контролирует список рассылки rabbitmq-users и только иногда отвечает на вопросы в StackOverflow.}

Answer 2

Вы игнорируете важные факторы правильного руководства, такие как постоянство и размер сообщения. В зависимости от размера сообщения, постоянства и рабочей нагрузки у вас есть три потенциальных узких места ресурса 1) ЦП 2) Сеть 3) Хранилище.Кроме того, существует также возможность возникновения узкого места в зависимости от количества клиентов в каждой очереди.