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

Question

我正在从论文的扩展版本学习Raft。在论文的第 5.2 节（领导人选举）中，它说：

如果追随者在称为选举超时的一段时间内没有收到任何通信，则它假设没有可行的领导者并开始选举以选择新的领导者。

同时，论文称在某些情况下 RPC 可能会被拒绝，例如当它包含较小的术语编号时。

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

---

编辑：

我目前的实现如下：

• RequestVote

  仅当服务器授予投票时重置超时

• AppendEntries

  如果其期限不小于服务器的
，则重置超时

这在大多数情况下工作得很好，但有时会导致长时间的选举。考虑一个具有 2 个服务器的 Raft 集群，两个服务器都是追随者。服务器 #1 具有更新的日志，但服务器 #2 具有更大的术语。

在此设置中，服务器 #1 必须连续启动 2 次选举才能成为领导者，这（直观地）发生在 <50% probability. If server #2 starts an election and timeouts, its term increases and the next election by server #1 will fail again. In practice this can cause the whole election to last for several seconds even if there are only a few servers. I wonder if there are some approaches to solve this problem (or if this is in fact not a problem).

Answer 1

充当 Follower 的 Raft 节点响应两种类型的请求：

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

如果 Follower 从当前 Leader 收到 AppendEntries，它应该执行所有检查（即请求中的术语、日志匹配），如果满足所有检查，Follower 应该追加从请求接收到的条目。当从当前 Leader 收到 AppendEntries 时，follower 还应该重置选举超时，因为 AppendEntries 也充当心跳（Leader 也会定期发送不带日志的 AppendEntries 请求，以防止 Follower 超时并开始新的选举）。

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

Answer 2

您是否正在实施 raft 并遵循 https://pdos.csail.mit.edu/6.824/labs/lab-raft.html.

中提到的实验

关于你的疑问，“如果有两台服务器，其中一台能胜选的服务器总是落后于启动选举，如何收敛得更快”

如果您阅读了论文的图 2，它提到如果 RPC 的期限较高并且更新其期限，则任何服务器都应该转换为追随者。该论文从未提及服务器是否应该真正重置其计时器。

计时器仅应在以下情况下重置：

1. 追加任期 >= 的领导者的条目。
2. 投票实际上授予了另一位候选人。
3. 作为候选人开始新的选举。

按照这个逻辑，第一个服务器将做两件事。

1. 将其术语更新为更高的术语，因为服务器 2 要求请求投票，而服务器 1 显然拒绝了。
2. 通过增加当前任期编号来开始新的选举。

由于上述一组操作，server-1 现在不会在 term seq 方面落后。

“理想情况下，您永远不会拥有 2 个节点的 Raft 集群，因此集群会更快地收敛。”

是的，确实如此。

拿一个案例。

50台服务器。

其中 26 个处于活动状态，其中 24 个存在网络分区。

26 号之一是领导者。日志正在照常复制。

现在这 24 台服务器恢复了，26 台活动服务器中只有 2 台可用，其余的与领导者一起进入网络分区。

当前状态。

26 个服务器处于活动状态。 24 个服务器处于非活动状态。

26台服务器中没有领导者。在这批新的 26 台服务器中，实际上只有两台服务器可以成为领导者，因为只有两台服务器拥有最新日志。

选举可能会运行相当长的一段时间，直到这两个服务器之一有机会在所有服务器成为候选人之前快速向所有服务器请求投票。