Как правильно организовать отказоустойчивость при работе к кластером RabbitMQ?

Question

[Дмитрий Лабутин]

Начну вопрос с аналогий.
Скажем MongoDB. Есть три ноды в репликасете. В connection string указываются все три и драйвер сам определяет, кто сейчас PRIMARY и с этой нодой работает.

А вот как быть с RabbitMQ? Собрали кластер кроликов.
Как правильно коннектиться к кластеру? Т.е. если одна нода упала, как продолжить работать с другой? В connection string к кролику вроде как указывается только один адрес (т.е. коннектимся всегда к одной ноде).

Как вариант, поставить перед кроликами HA-Proxy и он уже будет мониторить ноды и направлять запрос на живую. Это единственный вариант? Или есть более правильный?

Answer 1

[Сергей]

На уровне данных. Когда поднимается ResplicaSet в MongoDB, она понимает, что данные нужно дублировать на несколько нод. Когда создаётся кластер RabbitMQ (по факту это кластер Erlang-машин), то по всем машинам дублируются лишь метаданные (информация об обменниках, очередях и т.п.), но сами данные остаются жить на одной ноде (но прозрачно передаются/забираются, если клиент подключён к другой ноде кластера). У них есть статья в доке по отказоустойчивости к потери данных.

На уровне коннектов. Драйвер MongoDB открывает подключения до каждой ноды ReplSet (может быть лишь до какого-то их количества, не уверен точно) и, в зависимости от операции и её параметров, использует то или иное подключение. То есть поддержка ReplSet заложена на уровне драйвера. RabbitMQ работает на протоколе AMQP (нативный), который работает только с одной нодой брокера, скорее всего есть куча библиотек, которые обёртывают в себе подключение к нескольким серверам RabbitMQ (либо один коннект и другой поднимается по отказу первого, либо сразу несколько коннектов, которые дают балансировку и малый лаг при отказе одной ноды). Но, если нет либы для работы с несколькими нодами, то сделать её, думаю, особых проблем не составит.