Почему протокол RAFT отклоняет RequestVote с меньшим сроком?

В raft каждый узел отклоняет любой запрос с номером термина меньше, чем его собственный. Но зачем нам это нужно для RequestVote rpc? Если свойство полноты лидера выполняется, то узел может голосовать за этого кандидата, верно? Так почему отклонить запрос? Я не могу привести пример, где без этой дополнительной проверки при получении RequestVote мы можем потерять свою согласованность, безопасность и т.д.

Может быть, кто-то может помочь, пожалуйста?


raft consensus
person Ильяс Каримуллин    schedule 06.09.2020    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Кандидат с более низким сроком в RequestVote RPC имеет журнал, который может быть устаревшим с другими узлами, поскольку лидер может быть избран на более высокий срок и уже реплицировал запись на большинство серверов.

Если этот кандидат избран лидером, правила плота запрещают этому лидеру что-либо делать из соображений безопасности. Его RPC будут отклонены другими серверами из-за более низкого срока.

person Khanh TO    schedule 12.09.2020

arrow_upward
0
arrow_downward

Я думаю, что есть эти причины.

  1. Срок в Рафте монотонно увеличивается. Все запросы из предыдущих сроков являются запросами, сделанными на основе устаревшего состояния, и будут отклонены и возвращены только с текущим сроком и информацией о лидере.
  2. Любой избранный лидер должен иметь все зафиксированные журналы до выборов, кандидат с предыдущего срока вряд ли будет иметь все зафиксированные журналы, поскольку у него не будет зафиксированных журналов с текущего срока.
person HU PETER    schedule 12.10.2020