Обнаружение службы и алгоритм выбора лидера

Я занимаюсь некоторыми исследованиями для улучшения собственной службы обнаружения в моем проекте. У нас есть несколько узлов в кластере, отвечающих за службы обнаружения, которые доступны. Чтобы получить доступ к некоторой услуге, каждое клиентское приложение отправляет многоадресное сообщение всем этим узлам в кластере. Все узлы отвечают клиенту, и самый первый ответ определяет конкретный узел для дальнейшей работы. Это накладные расходы, и я думаю о том, чтобы использовать какой-то алгоритм выбора лидера, где только один лидер реагирует на клиентов. Можно ли использовать такой алгоритм для этой задачи?Обнаружение службы и алгоритм выбора лидера

источник

2014-02-13 Ivan Voroshilin

Выбор лидера или другие решения для решения проблем с консенсусом обычно реализуются, когда доступность критически важна. Это ситуация в вашем случае? – amit

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

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

источник

2014-02-13 11:55:56 abhinav

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

Позвольте мне нарисовать, как это работает простыми словами: 1. клиент отправляет многоадресный запрос -> 1..n узлов. 2. Все доступные узлы отвечают 3. Клиент инициирует дальнейший разговор с этим узлом, который сначала ответил клиенту сгенерированным sessionId и информацией о подключении конкретной службы. –

Итак, вы имеете в виду, как вы можете балансировать балансировку нагрузки? – abhinav

Обнаружение службы и алгоритм выбора лидера

ответ

Смежные вопросы