Raft 为什么不能直接 commit 前任的日志?

ideawu 2021-05-21 23:07

有一些文章, 包括Raft协议的论文, 已经从反例的角度解释了为什么不允许 Leader 直接 commit 前任的日志, 而是必须追加本任期的一条日志, 以达到隐式地 commit 前任的日志. 我想从 Raft 的几项原则的角度, 在逻辑上解释这个问题.

Raft 策略1: 节点的日志一旦 commit 便不可撤销

某个节点的一条日志, 一旦 commit 它, 那么就会对状态机造成不可逆的改变. 也许某些状态机有回滚功能, 但在 Raft 的架构中, 假设状态机不可回滚. 因此, 日志一旦 commit, 便不可撤销.

注意, 这里用的是"策略"一词, 表明这是人为规定的规则, 不是客观存在的定理.

Raft 策略2: 节点的日志在 commit 之前可被撤销

某个节点的一条日志, 如果还没有 commit, 那么未来有可能被其它的日志(相同 index 但不同 term)替换掉. 见后面分析什么场景下会出现日志被撤销(替换)的情况.

Raft 目标: 所有的节点最终应该 commit 相同的日志

这个目标是共识算法的基础特性, 不然就不叫共识算法.

Raft 常识: 不同的节点独立 commit

虽然 Leader commit 的一条日志, 但在上帝视角看, 其它节点还没有 commit, 也许过一天才 commit 也有可能.

问题的出现(4任 Leader)

第1任和第2任 Leader 针对同一个 index, 各自产生了两条不同 term 的日志, 均没有形成 quorum. 这时, 第3任 Leader 可以继承两者之中任意一个, 可以继承1, 也可以继承2. 注意: 任期数字之间不代表继承关系.

第3任会继承前任(假设继承第1任)的日志, 并复制到其它节点, 导致第2任的日志被替换掉了. 接着产生了新的第4任(继承第2任), 那么它又会导致第1任的日志被替换掉.

那么,为什么 commit 自己任期的日志, 就能确保日志不会被撤销呢? 原因有两条:

  1. Leader 永远不会主动撤销自己任期和前任的日志
  2. 新 Leader 必须包含 quorum 中最新的日志

Leader 如果能确认自己任期的日志已经复制给了 quorum, 就能确保这条日志一定会被新 Leader 以及未来的所有 Leader 继承.

但是, 只有自己任期的日志才能下这个结论, 前任的日志即使已经复制给了 quorum, 也有可能被撤销.

Related posts:

  1. Raft 协议和区块链
  2. Paxos和Raft读优化 – Quorum Read 和 Read Index
  3. Raft 选主优化之 PreVote
  4. 再谈 Paxos 和 Raft
  5. 为什么 Leader Based 的分布式协议 Raft 是更好的

[返回] [原文链接]