共同点：
1️⃣ 都采用多数派。
2️⃣ 都引入 Leader 角色，且一个强 Leader 的算法，只有 Leader 处理写请求。
不同点：
1️⃣ ZAB 划分阶段：崩溃恢复（领导者选举，成员发现，数据同步）、消息广播；Raft：领导者选举、日志复制
2️⃣ ZAB的协商阶段（消息广播阶段）分为两个阶段 Propose、Commit，移除了 2PC 的回滚；Raft 的协商阶段（日志复制阶段）被心跳机制 + 日志连续的特性优化为一个阶段。
3️⃣ ZAB 的协商阶段中 Follower 只会被动接受提案；Raft 中的协商阶段中 Follower 会参与提案值的决策（一致性检查）。
4️⃣ Raft 中日志只能从 Leader 流向 Follower，Follower 不能以任何形式覆盖掉 Leader 的数据；在 ZAB 中，当 Leader 晋升时，通过 NEWEPOCH 收集所有 Follower 的数据（Follower 通过 ACK 返回它历史的提案），来生成 Initial History。
5️⃣ 对历史日志 (上一任 Leader 日志) 的处理：Raft 认为之前 term 不明确提交状态的日志都是未提交的，需等待当前 Leader 提出新的日志项且达成共识后，才能提交之前的日志；ZAB 则认为上一任 Leader 提出的不明确提交状态的日志都是已提交的，并将这些日志复制到其他成员。
6️⃣ 对选举冲突问题的处理：Raft 引入随机超时时间，降低了选举冲突的可能性；ZAB 通过增加 myid 来解决选举冲突问题。
7️⃣ Raft 在一轮选举中每个成员只能投一票；ZAB 中成员由于会更新自己的选票重新广播，所以一轮选举中每个成员可投出多票。
8️⃣ 对于成员变更：Raft 有单节点成员变更 (One Server ConfChange) 和多节点联合共识 (Joint Consensus)；ZAB 3.5 之前没有动态成员变更，要想变更配置，只能停机更改配置文件再重启。