ZAB 🆚 Raft

共同点：

1️⃣ 都采用多数派。

2️⃣ 都引入 Leader 角色，且是一个强 Leader 的算法，只有 Leader 处理写请求。

3️⃣ 都保证了写的线性一致性和读的最终一致性。

不同点：

1️⃣ ZAB 划分阶段：崩溃恢复（领导者选举，成员发现，数据同步）、消息广播；Raft：领导者选举、日志复制

2️⃣ 对选举冲突问题的处理：Raft 引入随机超时时间，降低了选举冲突的可能性；ZAB 通过增加 myid 来解决选举冲突问题。

3️⃣ Raft 在一轮选举中每个成员只能投一票；ZAB 中成员由于会更新自己的选票重新广播，所以一轮选举中每个成员可投出多票。

4️⃣ ZAB 的协商阶段（消息广播阶段）分为两个阶段 Prepare、Commit，移除了 2PC 的回滚；Raft 的协商阶段（日志复制阶段）被心跳机制 + 日志连续的特性优化为一个阶段。

ZAB 需要两阶段是因为第二阶段要广播 COMMIT 消息让 Follower 提交到本地状态机；而 Raft 中 Follower 会在通过下一个 AppendEntries (日志 or 心跳) 的 leaderCommit 判断日志提交到本地状态机。

5️⃣ ZAB 的协商阶段中 Follower 只会被动接受提案；Raft 中的协商阶段中 Follower 会参与提案值的决策（一致性检查）。

6️⃣ Raft 中日志只能从 Leader 流向 Follower，Follower 不能以任何形式覆盖掉 Leader 的数据；在 ZAB 中，当 Leader 晋升时，通过 NEWEPOCH 收集所有 Follower 的数据（Follower 通过 ACK 返回它历史的提案），来生成 Initial History。

7️⃣ 对历史日志 (上一任 Leader 日志) 的处理：Raft 认为之前 term 不明确提交状态的日志都是未提交的，需等待当前 Leader 提出新的日志项且达成共识后，才能提交之前的日志；ZAB 则认为上一任 Leader 提出的不明确提交状态的日志都是已提交的，并将这些日志复制到其他成员。

8️⃣ 对于成员变更：Raft 有单节点成员变更 (One Server ConfChange) 和多节点联合共识 (Joint Consensus)；ZAB 3.5 之前没有动态成员变更，要想变更配置，只能停机更改配置文件再重启。

关于 Raft/ZAB 怎么保证数据一致性问题，怎么回答？

都确保所有已经在 Leader 上提交的事务最终被所有服务器提交。

Raft：选举 Leader 时， Leader 拥有的日志要至少和 Follower 的一样新 (lastLogTerm, LastLogInde)，才会被投票。保证了获得半数选票当选的 Leader 包含之前任期的所有被提交的日志条目。

ZAB：选择拥有 proposal 最大值 (epoch, zxid, myid) 最大的当选 Leader。则选出的 Leader 一定比大多数结点的 proposal 大，则肯定包含存所有被提交的 proposal。

对上一任 Leader 日志的处理。

Raft 认为之前 term 不明确提交状态的日志都是未提交的，需等待当前 Leader 提出新的日志项且达成共识后，才能提交之前的日志。

ZAB 则认为上一任 Leader 提出的不明确提交状态的日志都是已提交的，并将这些日志复制到其他成员。