В бумаге Плот, глава 5.1.,
Лидер обрабатывает все запросы клиентов (если
клиент связывается с подписчиком, подписчик перенаправляет его на
лидер).
Они предлагают вам связаться с любым узлом, и этот узел либо является лидером и выполняет работу, либо отвечает клиенту информацией о текущем лидере, а затем клиент повторяет запрос. Это позволяет клиенту знать только одного пира, и в конечном итоге клиент узнает, кто является лидером.
Поскольку все одноранговые узлы в кластере знают о других одноранговых узлах, можно реализовать перенаправление запросов на сам одноранговый узел. Таким образом, клиент не знает об уровне перенаправления и может знать только об одном узле.
Другим вариантом будет широковещательная рассылка запроса всем одноранговым узлам и проверка, что только один одноранговый узел ответит успешно (или ни одного, если выборы проводятся, и тогда можно повторить запрос). Это будет означать, что клиент должен знать обо всех одноранговых узлах, и если у вас динамический кластер Raft, вам также необходимо отслеживать изменения конфигурации кластера на клиенте.
Механизм, лежащий в основе этого, специфичен для etcd и их реализации.
Из документов, доступных на GitHub :
«MsgProp» предлагает добавить данные в свои записи журнала. Это особый
Тип, чтобы перенаправить предложения в лидера. Поэтому метод send перезаписывает
raftpb.Message термин с термином HardState, чтобы избежать присоединения его
местный термин для «MsgProp». Когда «MsgProp» передается «Step» лидера
метод, лидер сначала вызывает метод appendEntry для добавления записей
в свой журнал, а затем вызывает метод 'bcastAppend', чтобы отправить эти записи
его сверстники. При передаче кандидату «MsgProp» удаляется. Когда прошло
Последователь, «MsgProp» хранится в почтовом ящике подписчика (сообщения) при отправке
метод. Он хранится с идентификатором отправителя, а затем пересылается руководителю
пакет rafthttp.