Raft 共识算法习题精解：8道真题助你掌握日志与选举关键点

理解 Raft 算法的关键在于，不仅要看懂它的核心思想，还要能够应对各种复杂或边缘的场景。为此，我们精心准备了一系列习题，这些问题将引导你深入思考 Raft 日志、选举和安全的诸多细节。

Q1：日志任期合法性判断

下面的每张图都显示了一个 Raft 节点上可能存储的日志（日志内容未显示，只显示日志的 index 和任期号）。

假设每个日志都是独立的，下面的日志可能发生在 Raft 中吗？如果不能，请解释原因。

不能。

在 Raft 协议中，日志的任期号（term）必须单调递增。图中在 term 3 之后出现了 term 2，这违反了基本原则。

可以。

任期号从左至右为 1, 1, 2, 2, 2, 3，完全符合单调递增的规则。

可以。

任期号单调递增（1, 1, 3, 3, 5），第 6 个索引处无条目，这是被允许的（可能是新条目尚未写入）。

不能。

Raft 日志不允许“空洞”（gap）。具体来说，Leader 只能追加日志，并且 AppendEntries RPC 中的一致性检查永远不会允许在已存在的日志条目中间出现缺失。

Q2：日志记录安全性应用

下图显示了一个 5 节点集群中的日志（日志内容未显示）。哪些日志记录可以安全地应用到状态机？请解释你的答案。

日志记录 {1,1} 和 {2,1} 可以安全应用状态机。

Raft 的安全性规定：如果一条日志记录没有被存储在多数节点上，它就不能被安全地应用到状态机。因此，我们需要分析哪些节点可能当选 Leader，以及它们的当选是否会覆盖或删除现有的日志。

• 节点 S2 可以被选为 Leader，因为它日志至少和 S3、S4、S5 一样完整。如果它当选，它可能导致 {3,2}, {4,2} 和 {5,2} 被删除（通过日志覆盖），所以这些日志记录不能被安全地应用。
• 节点 S3 和 S4 不能被选为 Leader，因为它们的日志不够完整。
• 节点 S5 能被选举为 Leader，但是它的日志中包含了 {1,1} 和 {2,1}，所以它不会覆盖这两条记录。

综上，只有 {1,1} 和 {2,1} 可能被安全地应用到状态机。这道题很好地体现了为什么 Raft 能提供强一致性和高可用性保证，这也是设计和维护分布式系统时需要深入理解的核心。

Q3：日志一致性与历史场景推演

上图显示了一个 6 节点集群日志，此时刚刚选出任期 7 的新 Leader。对于每一个 Follower，给定的日志是否可能形成一个正常运行的 Raft 系统？如果是，请描述该情况如何发生的；如果不是，解释为什么。

(a) 不能。

根据 Raft 安全性规定（Leader Completeness Property），如果在不同节点的日志中，两条记录拥有相同的索引和任期号，那么它们之前的所有日志条目也必须全部相同。在 Leader 和 Follower (a) 的日志中，{5， 3} 都存在，但是 {4，3} 这个条目却不同。

(b) 不能。
理由同上 (a)。

(c) 可能。

Follower (c) 可能是第 6 任期的 Leader，其起始日志为 {1,1} 和 {2,1}，并且可能在其任期内写入了大量记录（term 为 6），而没有与我们第 7 任期的当前 Leader 进行通信。同时，这也假设当前 Leader 的 {3,3}、{4,3}、{5,3}、{6,5} 这几个日志记录在第 5 任期（上上个任期）没有被写入到 (c)，这是有可能发生的情况（网络分区导致）。

(d) 不能。

在一个日志中，任期和索引都必须是单调递增的。(d) 中任期号出现了下降（从 term 3 到 term 2）。

(e) 可能。

例如，(e) 是任期 1 的 Leader，它提交了日志 {1,1} 和 {2,1}。之后，它与其他节点失联（网络分区），但在其身份未发生变化的一段时间内，还在继续处理客户端请求，因此追加了一连串任期仍为 1 的新日志。

Q4：Leader 数据损坏的影响

假设硬件或软件错误破坏了 Leader 节点的数据，导致其为某个特定 Follower 存储的 nextIndex 值丢失了。这是否会影响系统的安全？请简要解释你的答案。

不影响安全性。

因为 Leader 会通过发送额外的 AppendEntries 请求，快速与 Follower 同步当前的日志水位。nextIndex 只是一个性能优化项，如果丢失，Leader 会通过一致性检查失败后回退的机制，逐步试探并最终找到正确的同步点。这个恢复过程虽然可能导致额外的网络交互，但不会破坏日志一致性或系统状态的安全性。如果你对网络通信和数据恢复机制感兴趣，可以深入了解更多。

Q5：从单数据中心到多数据中心的部署变更

假设你实现了一个 Raft 系统，并将它部署在同一个数据中心的所有服务器上。现在假设你要将系统部署到分布在世界各地的不同数据中心的不同服务器，与单数据中心版本相比，多数据中心的 Raft 需要做哪些更改？为什么？

我们需要将选举超时（election timeout） 参数设置得更长。

因为跨数据中心的网络延迟（RTT）会显著增加。选举超时时间应该比预期的广播往返时间长得多，这样候选节点才有足够的机会在超时之前完成一次选举（发送 RequestVote 并收到多数派回复）。系统的其余部分（如日志复制逻辑）不需要任何修改，因为它不依赖于物理时钟/绝对时序，只依赖于逻辑上的时序比较。

Q6：持久化存储丢失的后果

每个 Follower 都持久化存储了 3 个字段：当前任期（currentTerm）、最近的投票（votedFor）、以及所有接受的日志记录（entryLogs）。

• a. 假设 Follower 崩溃了，并且当它重启时，它最近的投票信息（votedFor）已丢失，该 Follower 重新加入集群是否安全？

不安全。

这将允许一个节点在同一任期内投票两次，这可能会导致每个任期产生多个 Leader 节点（脑裂）。

举例来说：

1. S1 获得 S1 和 S2 的投票，并且成为任期 2 的 Leader。
2. S2 重启，丢失了它在任期 2 中的投票记录。
3. S3 获得 S2 和 S3 的选票，并且成为任期 2 的第二任 Leader。

• b. 假设崩溃期间 Follower 的日志的最后一部分被删除了，该 Follower 重新加入集群是否安全？

不安全。

因为 Raft 依赖 “已写入本地日志的条目不会丢失（持久化）” 这一保证。如果 Follower 崩溃会丢日志，则可能让一个日志更旧的候选人当选 Leader，进而覆盖已经提交的条目，破坏安全性。这就是为什么在实际的数据库或存储系统中，可靠的持久化机制至关重要。

举例来说：

1. S1 成为任期 2 的 Leader，并在自己和 S2 上追加写了 index=1, term=2, value=X，并设置 committedIndex=1，然后返回已提交的值 X 给客户端。
2. S2 重启，并且丢失了这条日志。
3. S3（没有任何日志）成为任期 3 的 Leader，因为它的空日志也至少与 S2 一样完整（S2 日志为空）。S3 在自己和 S2 上追加写 index=1, term=3, value=Y，并设置 committedIndex=1，然后返回已提交的值 Y 给客户端。这样，已提交的值 X 就被覆盖了。

Q7：旧 Leader 在选举后的行为分析

即使其它节点认为 Leader 已经崩溃，并重新选出了新的 Leader 后，（旧的）Leader 依然可能继续运行。新的 Leader 将与集群中的多数派通信并更新它们的任期，因此，老的 Leader 将在与多数派中的任何一台服务器通信后立即 “下台”。然而，在此期间，它也可以继续充当 Leader，并向尚未和新 Leader 通信/同步的 Follower 发出请求。

在选举结束后，老的 Leader 不能提交任何新的日志记录，因为这至少需要联系选举多数节点中的任意一个。但是，旧的 Leader 仍然可能把早先任期内创建的某些日志条目推进 commitIndex（或至少让某些 Follower 执行追加成功）。如果可以，请解释这种情况是如何发生的，并讨论这是否会给 Raft 带来问题。如果不能发生这种情况，请说明原因。

可以发生，而且这是 Raft 里一个 “正常且必须允许” 的竞态场景，并不会破坏 Raft 安全性，但会影响客户端何时得到响应（过程中可能被重定向/重试）。

1. 旧 Leader 可能成功执行 AppendEntries 吗？
可能。 新 Leader 当选后，并不会立刻 “实时地” 通知到所有节点；一些 Follower 可能还没收到更高 term 的消息，仍会接受旧 Leader 的 AppendEntries（因为旧 Leader 的 term 不落后而且 prevLog 还匹配）。因此旧的 Leader 可以在短时间内向部分 Follower 复制日志成功，甚至让一些日志条目在更多节点上被复制。

2. 旧 Leader 还能把日志提交吗？
分情况讨论。

• 情况 A：提交 “旧任期条目”（old term entries）——有可能。
  Raft 的提交有个关键细节：Leader 的 commitIndex 规则是，当某个日志索引 N 已存储在多数派节点上，且 log[N].term == currentTerm，Leader 才能把 commitIndex 推进到 N。但是，旧任期条目可能通过 “间接提交” 变成已提交：一旦某个更高索引的 “当前任期条目” 提交了，那它之前的日志条目（包括旧任期的）也随之被认为提交。
  因此，旧 Leader 可能在失去领导权之前，就已经拥有了某些 “多数派复制” 的条件，只是还没来得及更新 commitIndex 通知 follower；或者它可能从某些 follower 的成功响应中，刚好凑齐它所认为的多数派数量（这个多数派可能与新 Leader 的多数派重叠/不重叠）从而推进它的 commitIndex。新 Leader 当选并不意味着旧 Leader 立刻停止推进它本地的 commitIndex；在旧 Leader 发现更高 term 并退位之前，它仍按照 Leader 逻辑运转。

• 情况 B：提交选举结束后新追加的条目 ——不能。
  旧 Leader 和投票给新 Leader 中的任一节点通信，旧 Leader 都会看到更高 term，然后立刻退位。反过来说，旧 Leader 不与多数派通信，就不可能形成多数派复制，当然也无法提交新条目。所以：选举完成后，旧 Leader 不可能再提交在新 Leader 选举后才创建的日志条目。

3. 这会给 Raft 带来问题吗？
不带来安全性问题，原因在于 Raft 的两个关键性质：

1. 日志新旧限制保证了，新 Leader 一定包含所有已提交条目。如果旧 Leader 在竞态窗口里把某条目判定为已提交，那么该条目必然已经在某个多数派上；而任何当选的新 Leader 必须从多数派中获得选票，并且其日志至少和投票者一样新，从而不会缺失已提交条目。
2. 旧 Leader 即使错误地 “认为自己提交了”，它最多造成客户端请求失败后重试，或收到重定向（发现 term 变大后）。

Q8：集群成员变更的陷阱分析

在集群成员变更过程中，如果当前 Leader 不在 C-new 中，一旦 C-new 的日志记录被提交，它就会退位。然而，这意味着有一段时间，Leader 不属于它所领导的集群（Leader 上存储的当前配置条目是 C-new，其中不包括 Leader）。

假设修改算法，如果 C-new 不包含 Leader，则使 Leader 在其日志存储了 C-new 时就立即下台。这种方法可能发生的最坏情况是什么？根据对算法的理解，有两种可能的正确答案。

这会破坏 Raft 成员变更的关键目标：在变更期间保持可用性并且保证只有一个能推进提交的 Leader。

最坏情况 1：直接造成 “无法推进”
假设写入 C-new 就退位，可能会出现：

1. 当前 Leader 属于 C-old，不属于 C-new，创建条目 C-new，把它写入自己日志并开始复制。
2. 只要 Leader 自己写入了该条目就立刻退位，于是 C-new 还没提交（需要多数派确认）就失去了 Leader。新 Leader 选举发生，但新 Leader 未必已经收到了 C-new。
3. 新 Leader 可能也会尝试发起配置变更/复制该条目。
4. 但如果每次只要新 Leader 复制到自己就退位，就会形成死循环...

系统可能陷入持续选举与反复重试，表现为长期不可用。只要网络稍有抖动，导致日志条目迟迟不能在需要的多数派上稳定复制，就会不断触发 “写入即退位”，形成活锁。

最坏情况 2：出现两个不同配置的 Leader

• 旧 Leader L 在 term T 写入 C-new 后立刻退位，但 C-new 还没提交。
• 某个节点在 C-old 视角下当选 Leader（因为大多数节点仍停留在 C-old）。
• 同时另一侧一些节点可能已经接受了 C-new，从而出现一部分节点按旧配置投票/算多数派，另一部分节点按新配置投票/算多数派。
  在实现正确的联合共识算法中，未提交的配置条目不能生效，因此安全性不会被破坏；但是这种 “提前退位” 会极大增加出现以下现象的概率与持续时间，导致频繁选举、不同节点对 “当前配置” 认识不一致，导致长期无法形成有效多数派，选举无法收敛。

所以 Raft 论文要求 Leader 提交后再退位，因为那样能保证：

• 在 C-old,new 阶段，Leader 仍然能同时与旧、新两边的多数派交互，推进条目提交。
• 只有当 C-new 真正提交并生效后，才允许旧 Leader 退出，从而保证领导权平滑转移且系统持续可用。

扩展阅读

• https://ongardie.net/static/raft/userstudy/raft.pdf
• https://ongardie.net/static/raft/userstudy/rubric.pdf
• https://ongardie.net/static/raft/userstudy/quizzes.html

希望这份Raft习题精解能帮助你巩固对分布式共识算法的理解。如果你在实践中有更多心得或疑问，欢迎来到云栈社区与更多开发者交流探讨。