Почему или почему бы не использовать RPC RequestVote в качестве пульса в реализации Raft? - PullRequest
0 голосов
/ 26 ноября 2018

Как показано в статье, мы используем пустой RPC AppendEntries для сердцебиения.Тогда как насчет RPC RequestVote?Когда FOLLOWER или CANDIDATE получает RPC-запрос RequestVote, предполагается ли также сброс таймаута выборов?Почему или почему бы не сделать этого?
Одно из преимуществ, на мой взгляд, состоит в том, что когда RPC-запрос RequestVote также рассматривается как пульс, мы потенциально можем предотвратить состояние нескольких кандидатов.Поскольку несколько кандидатов могут разделить голоса и занять больше времени на этапе выборов.При использовании этого в качестве пульса RPC-запросы RequestVote от одного кандидата сбрасывают таймер выборов, так что другие действующие одноранговые узлы с меньшей вероятностью истекают и также становятся кандидатами.

1 Ответ

0 голосов
/ 27 ноября 2018

Ну, в этом нет ничего небезопасного.Но проблема в том, что узлы, которые не могут победить на выборах, могут начать их.Таким образом, если узел, который не может победить, начинает выборы и запрашивает голоса у всех других узлов, сброс их таймеров заблокирует выборы.А поскольку кандидат, который не может победить, сначала запустил таймер, он, скорее всего, также остановит тайм-аут и начнет сначала другие выборы, таким образом снова блокируя кластер, и другие выборы, и т. Д.

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

...