Зеркальное отображение очереди кластеризации RabbitMQ для обеспечения высокой доступности: получить IP-адрес главного узла для очереди в момент времени t

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

Из документации:

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

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

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

PS: Также кажется плохим иметь узлы за балансировщиком нагрузки, так как если есть какой-то сетевой раздел (который может возникать даже с узлами в той же локальной сети), то мы потенциально можем столкнуться с узлами, которые не могут связываться с master для очереди ИЛИ, что еще хуже, может быть разделенный мозг, который мы будем развивать, если хотите.


rabbitmq rabbitmqctl
person Steve P.    schedule 09.05.2016    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

например. для очереди curl -i -u guest:guest http://[HOST]:[PORT]/api/queues/[VHOST]/[QUEUE] вернет следующую полезную нагрузку:

{
  "messages": 0,
  "slave_nodes": [
    "rabbit@node1",
    "rabbit@node0"
  ],
  "synchronised_slave_nodes": [
    "rabbit@node0",
    "rabbit@node1"
  ],
  "recoverable_slaves": [
    "rabbit@node0"
  ],
  "state": "running",
  "name": "myQueue",
=>"node": "rabbit@node2"
}

Для myQueue ваш клиент предпочтет подключение к node2 (главный узел myQueue), чтобы минимизировать HOP.

Я не уверен, стоит ли это затрат. Это увеличит количество подключений и сложность клиента. Буду рад получить отзыв, если вы что-нибудь реализуете.

person Nicolas Labrot    schedule 10.05.2016
comment
Если подумать, дополнительный прыжок, вероятно, не так важен, как сложность, которую представляет попытка пропустить этот прыжок. - person Steve P.; 10.05.2016

arrow_upward
1
arrow_downward

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

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

поэтому слова master и slave относятся к очередям, а не узлам rabbitmq, я предполагаю, что здесь возникает путаница. Как только я прочитал вопрос, а затем снова документы, это заставило меня задуматься на некоторое время, но мы не можем сказать, что зеркальная очередь состоит из главного и подчиненных узлов rabbitmq;)


Что касается балансировки нагрузки для (из?) кластера, вы можете сделать это так, чтобы клиенты всегда подключались к узлу rabbitmq, который активен, используя фактический балансировщик нагрузки или делая клиентов «умнее», т. е. они должны повторно подключиться к IP другого узла, если (исходный) главный узел выходит из строя. Рекомендуется первый подход, просто найдите Подключение к кластерам от клиентов здесь.

person cantSleepNow    schedule 10.05.2016