為什么或為什么不在Raft實現中將RequestVote RPC用作心跳？

Question

如本文所述，我們將空的AppendEntries RPC用於心跳。 那RequestVote RPC又如何呢？ 當FOLLOWER或CANDIDATE收到RequestVote RPC調用時，是否還應該重置選舉超時？ 為什么或為什么不這樣做？
我的一個好處是，當RequestVote RPC調用也被視為心跳時，我們可以潛在地防止出現多個候選條件。 由於多個候選人可能會分裂投票並在選舉階段花費更長的時間。 通過將其用作心跳，來自一個候選者的RequestVote RPC調用將重置選舉計時器，從而使其他活動對等節點也不太可能超時並也成為候選者。

Answer 1

好吧，可能沒有任何本質上不安全的東西。 但是問題是不能贏得選舉的節點仍然可以開始選舉。 因此，如果無法贏得勝利的節點開始選舉並要求所有其他節點投票，則重置其計時器將阻止選舉。 而且由於無法取勝的候選人首先啟動其計時器，因此它也可能會超時並首先啟動另一個選舉，從而再次阻止集群，並再次進行選舉，依此類推。

當然，解決此問題的方法可能是僅在投票時重置選舉超時。 這可能是安全的。 畢竟，選舉超時還是隨機的。 但是問題是它是否有效。 這不會阻止拆分投票，因為它不會阻止多個節點同時請求投票，並且在拆分投票期間，它只會使選舉花費更長的時間。 出於這個原因，我懷疑表決前協議的效率要高得多，並且可能避免分開表決，並且可以避免。