Как было сказано в документе, мы используем пустой AppendEntries RPC для тактового импульса. Тогда как насчет RequestVote RPC? Когда FOLLOWER или CANDIDATE получают RPC-вызов RequestVote, предполагается ли также сбросить тайм-аут выборов? Почему или почему не делать этого?
На мой взгляд, одно из преимуществ состоит в том, что когда вызов RequestVote RPC также обрабатывается как сердцебиение, мы потенциально можем предотвратить состояние нескольких кандидатов. Поскольку несколько кандидатов могут разделить голоса и занять больше времени на этапе выборов. Используя это в качестве контрольного сигнала, RPC-вызовы RequestVote от одного кандидата сбрасывают таймер выборов, так что другие действующие одноранговые узлы с меньшей вероятностью прервутся по таймауту и также станут кандидатом.
Почему или почему не использовать RequestVote RPC в качестве контрольной точки в реализации Raft?
Ответы (1)
Что ж, вероятно, в этом нет ничего небезопасного. Но проблема в том, что узлы, которые не могут выиграть выборы, все равно могут их начать. Итак, если узел, который не может победить, начинает выборы и запрашивает голоса у всех других узлов, сброс их таймеров заблокирует выборы. И поскольку кандидат, который не может выиграть, первым запустил свой таймер, он, скорее всего, также отключится по таймауту и сначала запустит другие выборы, тем самым снова заблокировав кластер, другие выборы и так далее.
Конечно, исправить это можно только в том, чтобы сбросить тайм-ауты выборов, когда голосование подано. Это могло быть безопасно. В конце концов, тайм-ауты на выборах в любом случае рандомизируются. Но вопрос в том, насколько это эффективно. Это не помешает разделению голосов, поскольку не мешает нескольким узлам запрашивать голоса одновременно, а во время разделенного голосования это приведет лишь к тому, что выборы займут гораздо больше времени. Я подозреваю, что протокол до голосования намного более эффективен по этой причине и, вероятно, позволяет избежать разделения голосов, а также их можно избежать.
