В настоящее время я сам внедряю алгоритм консенсуса Рафта и сталкиваюсь со следующей проблемой.Предположим, что есть 4 узла (A, B, C и D), поэтому запись в журнале может быть зафиксирована с более чем 2 голосами.Теперь мы запускаем кластер и выбираем лидера A с term = 0
.Затем происходят следующие вещи:
- Отключение подписчика B / D.
- Лидер A create
LogEntry
X. - Лидер A пытается выполнить репликацию на все узлы ив конечном итоге происходит сбой, потому что только 2 узла (A и C).
- Узел B переподключается и тайм-аут, он начинает выборы с новым
term = 1
. - Узел A потерял свое лидерство, потому что он получил Узел
RequestVote
RPC B. - Узел B не может выиграть выборы, потому что у него нет
LogEntry
X. Таким образом, в кластере нет Лидера. - Узел Тайм-аут и времяснова выбран в качестве лидера.
- Лидер A успешно реплицирует
LogEntry
X в B. Теперь узлы A / B / C имеют точно такой же LogEntry
X, что (index = 0, term = 0)
.Однако, согласно статье Плот, Лидер А не может зафиксировать X, хотя он сгенерирован сам, и большинство согласилось с X.
Плот никогда не фиксирует записи журнала из предыдущих терминов путем подсчета реплик.Только записи в журнале с текущего срока лидера фиксируются путем подсчета реплик;
- Предположим, что от клиента для репликации больше нет
LogEntry
s, поэтому LogEntry
X остается незафиксированным.
Мои вопросы:
- Это реальная проблема?
- Есть ли какие-то решения для этого?На самом деле уже есть некоторые сообщения о SoF, которые подчеркивают важность этого правила.И в этом посте , кажется, говорится, что мы можем создать копию Y X и реплицировать Y. Это работает или, возможно, существует общее решение?