如论文中所述，我们使用空的 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.因此，如果无法获胜的节点开始选举并请求所有其他节点投票，则重置它们的计时器将阻止选举。并且由于无法获胜的候选人首先启动了计时器，它也可能会超时并首先开始另一次选举，从而再次阻塞集群，并进行另一次选举，依此类推。
当然，解决此问题的方法可能是仅在投票时重置选举超时。这可能是安全的。毕竟，无论如何，选举超时都是随机的。但问题是它是否有效。它不会阻止 split 投票，因为它不会阻止多个节点同时请求投票，并且在 split 投票期间，它只会使选举花费更长的时间。我怀疑出于这个原因，预投票协议(protocol)的效率要高得多，并且可能会避免 split 投票，而且它们是可以避免的。
关于algorithm - 为什么或者为什么不在 Raft 实现中使用 RequestVote RPC 作为心跳？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/53483543/