В плотном кластере давайте создадим узел, который хочет стать лидером, и назовем его кандидатом. Все остальные узлы, включая текущего лидера, мы будем просто называть пирами.
Давайте посмотрим, что произойдет, когда пир получит RequestVoteRPC от кандидата.
Если термин пира больше, чем получено в запросе (срок кандидатов), в голосовании будет отказано. Ответ будет содержать термин однорангового узла, поэтому кандидат перейдет в состояние последователя и обновит его, как только получит ответ. Это обеспечит, чтобы срок запроса равным голосом равноправного члена равнялся сроку подачи равным голосом равного.
В противном случае равноправный участник должен решить, что делать.
Если Срок однорангового узла меньше полученного в запросе (срок кандидатов), этот участник преобразуется в последователя и обновляет свой текущий срок до полученного от кандидата, прежде чем продолжить решение. Это обеспечит совпадение срока запроса равноправного участника, запрашивающего голос.
Существует вероятность того, что несколько равных преобразуются в состояние кандидата, и равный нам " Наблюдатели уже проголосовали за кандидата. В этом случае переменная votedFor не будет null, и мы не можем предоставить право голоса второму (или любому другому) кандидату. Но мы также должны быть осторожны, потому что мы можем получить повторный запрос RequestVoteRPC (от того же кандидата) и из-за этого нам нужно проверить, равно ли votedFor идентификатору кандидата, чей запрос мы наблюдаем. Если votedFor равно текущему идентификатору кандидата, мы предоставим голос.
Подведем итог, мы предоставим голос, если переменная votedFor равна null или равна идентификатору кандидата. ,
Я намеренно исключил условие, что для предоставления права голоса журнал кандидата должен быть хотя бы актуальным в примере, но не забывайте, что это также важно.
Каждый участник может предоставить один голос в течение одного срока , и поскольку условия будут синхронизировать c во время общения, срок участника, отдавшего голос, будет будет таким же, как термин, требующий голосования.