Насколько распределенными должны быть очереди в кластере RabbitMQ?

Question

Предположим, у вас есть небольшая система rabbitmq из 3 узлов, которая должна обрабатывать более 100 очередей с достаточно большим объемом в одном обмене.Учитывая, что очереди существуют только на узле, на котором они созданы (мы не используем реплицированные очереди высокой доступности), каков наилучший способ создания очередей?Есть ли какое-то преимущество в том, что очереди распределяются между узлами кластера, или лучше хранить их все на одном узле, а rmq выполняет маршрутизацию?

Answer 1

Это зависит от вашего приложения, на самом деле.

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

1. очередь, которая содержит это сообщение, находится на этом узле или
2. , если потребитель подключился к этому узлу и запросил сообщение.

Как правило, вы должны стремиться объявлять очереди на узлах, к которым будут подключаться как издатели, так и потребители для этой очереди. Другими словами, вы должны стремиться соединить издателей и потребителей с узлом, который содержит очереди, которые они используют. Это предполагает, что вы пытаетесь сохранить используемую пропускную способность в целом.

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

Последнее, о чем нужно подумать, это память и дисковое пространство. Очереди хранят сообщения в основной памяти, а в случае отказа - на диск. Таким образом, если вы объявите все свои очереди в одном месте, это приведет к одному «перегруженному» узлу и двум узлам с резервной памятью.

Answer 2

В рамках перехода к резервированию и отработке отказа в приложении, над которым я работаю, я только что завершил настройку кластера RabbitMQ за прокси-сервером, и все мои издатели и потребители подключаются через прокси, что округляетРобинс соединения с отдельными узлами, как они приходят от клиентов.До обновления RabbitMQ до 2.7.1 казалось, что это довольно равномерно распределяет очереди по отдельным узлам, хотя это, конечно, будет в значительной степени зависеть от того, как ваш прокси-сервер уравновешивает запросы и когда ваши клиенты пытаются подключиться (и объявить очередь)...

Сказав все это, я просто обновился до RabbitMQ 2.7.1, который был довольно безболезненным, и дал нам очереди HA, что является довольно большой победой для наших приложений.В любом случае, если вы заинтересованы в настройке и считаете, что это будет полезно для вашей проблемы с очередью, я был бы рад поделиться настройкой.