Raft follower 应该什么时候记录 RPC?

When should a Raft follower record an RPC?

我正在从 paper's extended version 学习 Raft。在论文的第 5.2 节(领导人选举)中,它说:

If a follower receives no communication over a period of time called the election timeout, then it assumes there is no viable leader and begins an election to choose a new leader.

同时,该论文说在某些情况下可以拒绝 RPC,例如当它包含较小的任期号时。

我的问题是:follower 什么时候应该将 RPC 识别为有效的“通信”并记录下来以防止自己超时?


编辑:

我目前的实现如下:

这在大多数情况下工作正常,但有时会导致选举时间过长。考虑一个有 2 个服务器的 Raft 集群,都是跟随者。服务器 #1 有更新的日志,但服务器 #2 有更长的期限。

在此设置中,服务器 #1 必须连续开始 2 次选举才能成为领导者,(凭直觉)发生这种情况的概率 <50%。如果服务器 #2 开始选举并超时,则其任期增加并且服务器 #1 的下一次选举将再次失败。实际上,即使只有几台服务器,这也会导致整个选举持续几秒钟。我想知道是否有一些方法可以解决这个问题(或者这实际上不是问题)。

作为Follower的Raft节点响应两种类型的请求:

  • 追加领导者的条目
  • 请求候选人投票

如果 Follower 从当前 Leader 收到 AppendEntries,它应该做所有的检查(即来自请求的术语,日志匹配),如果所有检查都满足,Follower 应该附加从请求中接收到的条目. Follower 在收到当前 Leader 的 AppendEntries 时也应该重置选举超时时间,因为 AppendEntries 也起到心跳的作用(Leader 也会定期发送不带日志的 AppendEntries 请求,以防止 Follower 超时并开始新的选举)。

如果 Follower 收到 RequestVote RPC,并且如果 Follower 决定将其投票给该 Candidate,则 Follower 也将重置其选举超时。