为什么或者为什么不在 Raft 实现中使用 RequestVote RPC 作为心跳？
Why or why not use RequestVote RPC as heartbeat in Raft implementation?
如论文中所述，我们使用空的AppendEntries RPC 进行心跳。那么 RequestVote RPC 呢？当 FOLLOWER 或 CANDIDATE 收到 RequestVote RPC 调用时，是否也应该重置选举超时？为什么或为什么不这样做？
我认为的一个好处是，当 RequestVote RPC 调用也被视为心跳时，我们可以潜在地防止多个候选人的情况。由于多名候选人可能会分散选票，因此在选举阶段需要更长的时间。通过将其用作心跳，来自一位候选人的 RequestVote RPC 调用将重置选举计时器，这样其他活跃的同行就不太可能超时并成为候选人。
好吧，它可能没有任何内在的不安全之处。 But the problem is nodes that can’t win an election can still start one.因此，如果无法获胜的节点开始选举并请求所有其他节点投票，则重置它们的计时器将阻止选举。而且由于无法获胜的候选人首先启动了它的计时器，它也可能会超时并首先开始另一次选举，从而再次阻塞集群，并进行另一次选举，依此类推。
当然，解决此问题的方法可能是仅在投票时重置选举超时。这可能是安全的。毕竟，无论如何，选举超时都是随机的。但问题是它是否有效。它不会阻止分裂投票，因为它不会阻止多个节点同时请求投票，并且在分裂投票期间，它只会使选举花费更长的时间。我怀疑出于这个原因，预投票协议效率更高，并且可能避免分裂投票以及可以避免的投票。
如论文中所述，我们使用空的AppendEntries RPC 进行心跳。那么 RequestVote RPC 呢？当 FOLLOWER 或 CANDIDATE 收到 RequestVote RPC 调用时，是否也应该重置选举超时？为什么或为什么不这样做？
我认为的一个好处是，当 RequestVote RPC 调用也被视为心跳时，我们可以潜在地防止多个候选人的情况。由于多名候选人可能会分散选票，因此在选举阶段需要更长的时间。通过将其用作心跳，来自一位候选人的 RequestVote RPC 调用将重置选举计时器，这样其他活跃的同行就不太可能超时并成为候选人。
好吧，它可能没有任何内在的不安全之处。 But the problem is nodes that can’t win an election can still start one.因此，如果无法获胜的节点开始选举并请求所有其他节点投票，则重置它们的计时器将阻止选举。而且由于无法获胜的候选人首先启动了它的计时器，它也可能会超时并首先开始另一次选举，从而再次阻塞集群，并进行另一次选举，依此类推。
当然，解决此问题的方法可能是仅在投票时重置选举超时。这可能是安全的。毕竟，无论如何，选举超时都是随机的。但问题是它是否有效。它不会阻止分裂投票，因为它不会阻止多个节点同时请求投票，并且在分裂投票期间，它只会使选举花费更长的时间。我怀疑出于这个原因，预投票协议效率更高，并且可能避免分裂投票以及可以避免的投票。