2 узла, компонент брокера сообщений высокой доступности - PullRequest
0 голосов
/ 01 апреля 2020

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

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

Я сразу подумал о распределенном решении, таком как Kafka или rabbitMQ, но для всех «кластерных решений» требуется как минимум 3 узла для высокой доступности. 2 узла, и у нас может получиться сплит-мозг.

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

Звучит ли эта мысль в моем случае правдоподобно? Любые другие предложения?

Если так, есть ли какой-нибудь инструмент брокера сообщений с нативной поддержкой для такого рода функций?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...