Как правильно организовать хранение и обработку связи между идентификаторами и адресами узлов?

Question

Элеонора

программирование , кластеры

Как правильно организовать хранение и обработку связи между идентификаторами и адресами узлов?

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

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

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

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

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

Буду благодарен за любые идеи и примеры проектов, которые могут помочь решить эту проблему.

23 сентября 2023 г. 13:18

Ответы на вопрос 2

Похожие вопросы

Answer 1

Организация хранения и обработки связи между идентификаторами и адресами узлов в распределенной системе, реплицирующейся по алгоритму Raft, может быть реализована различными способами. Вот несколько возможных подходов:

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

2. Использование распределенного хранилища: Вместо централизованной базы данных вы можете использовать распределенное хранилище данных, такое как Apache ZooKeeper или Consul. В таком случае, каждый узел будет регистрироваться в хранилище с указанием своего идентификатора и адреса. Клиентская библиотека может подписаться на изменения в хранилище и получать оповещения о добавлении или удалении узлов.

3. Использование динамической конфигурации: Вместо подключения к каждому узлу для определения идентификаторов, вы можете использовать динамическую конфигурацию, где каждый узел будет предоставлять информацию о себе, включая свой идентификатор и адрес. Клиентская библиотека может получать эту информацию из общего ресурса, такого как файл конфигурации или сервис обнаружения, и использовать ее для построения отображения Id - адрес узла.

4. Использование peer-to-peer сети: Если ваше распределенное приложение построено на основе peer-to-peer сети, вы можете использовать подобные сетевые протоколы для передачи информации об узлах, включая идентификаторы и адреса. Каждый узел может сообщать о себе другим узлам, и клиентская библиотека может получать эту информацию в процессе установления соединения.

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

Answer 2

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