Raft 和 ZAB 有什么区别和联系？
简化版
Raft 和 ZAB 都是 Leader-Follower 架构，都通过多数派复制日志来保证已提交数据不丢，都适合构建强一致副本状态机。区别是 Raft 是通用共识算法，明确拆分 Leader 选举、日志复制和安全性；ZAB 是 ZooKeeper 的原子广播协议，更贴近 ZooKeeper 的事务日志复制和崩溃恢复。Raft 用 term 和 log index 描述日志，ZAB 用 epoch 和 zxid 描述事务顺序。
详细版
共同点：二者都有 Leader，写请求由 Leader 排序；提交依赖多数派 ACK；Leader 故障后要选新 Leader 并恢复日志；安全性都依赖多数派交集，确保已提交日志进入后续 Leader。
区别：Raft 的协议表述更通用，强调强 Leader、随机选举超时、RequestVote、AppendEntries、日志匹配和 Leader 完整性。ZAB 是 ZooKeeper 的专用原子广播协议，强调崩溃恢复和消息广播两个模式，使用 zxid 标识全局事务顺序。
在面试中可以说：Raft 更适合讲通用共识算法，ZAB 更适合讲 ZooKeeper 如何复制事务。二者思想接近，但术语、实现细节和服务语义不同。
完整版教学
一、先说共同目标
Raft 和 ZAB 都服务于同一类问题：多个副本如何以相同顺序执行写操作。只要顺序一致，每个节点应用相同事务后状态就会一致。它们都不是简单主从复制，因为普通主从复制可能主节点写完就返回，主挂后丢数据；Raft 和 ZAB 都要求关键写入经过多数派确认。
因此二者的共同底层逻辑是 Leader 排序和 Quorum 提交。Leader 负责给写请求排全局顺序，Follower 复制日志或事务，多数节点确认后才提交。Leader 故障后，新 Leader 必须继承已提交历史。
二、Raft 的特点
Raft 是面向可理解性设计的通用共识算法。它把协议拆成三个模块：Leader 选举、日志复制、安全性。节点角色有 Follower、Candidate、Leader；任期用 term 表示；日志条目用 index 和 term 标识；核心 RPC 是 RequestVote 和 AppendEntries。
Raft 的规则描述非常清楚：候选人日志必须足够新才能拿票；AppendEntries 用 prevLogIndex 和 prevLogTerm 找共同前缀；当前任期日志多数复制后推进提交。这些规则让 Raft 很适合用来讲“共识系统为什么不会丢已提交日志”。
三、ZAB 的特点
ZAB 是 ZooKeeper 的原子广播协议，天然绑定 ZooKeeper 的事务模型。它常被描述为两个模式：崩溃恢复和消息广播。恢复模式负责选出新 Leader、同步事务历史、处理未提交尾部；广播模式负责 Leader 为写请求分配 zxid，并把 Proposal 广播给 Follower，多数 ACK 后 Commit。
ZAB 的 zxid 很关键，包含 Leader epoch 和事务递增编号。epoch 类似任期，用来区分新旧 Leader；递增编号表示事务顺序。ZooKeeper 的所有写操作都通过这条有序事务日志应用。
四、关键差异怎么回答
第一，定位不同。Raft 是通用共识算法，很多系统可以采用；ZAB 是 ZooKeeper 为协调服务设计的原子广播协议。第二，术语不同。Raft 讲 term、log index、RequestVote、AppendEntries；ZAB 讲 epoch、zxid、Proposal、ACK、Commit。第三，协议叙述重点不同。Raft 强调选举和日志复制的可理解性，ZAB 强调 Leader 崩溃恢复和事务广播。
但不要把二者说成完全无关。它们的工程形态很接近，都是强 Leader、多数派、顺序日志、故障恢复。面试时可以先讲共同点，再讲差异，这样答案更稳。
五、读写语义上的差异
Raft 本身描述的是如何复制日志和实现线性一致状态机，具体读策略由系统实现决定，例如 ReadIndex、lease read、提交 no-op 等。ZooKeeper 基于 ZAB 保证写事务顺序一致，但读请求默认可能由 Follower 本地处理，因此可能不是最新读；需要更强读语义时可以配合 sync。
这个差异说明：共识协议保证复制日志安全，但最终系统暴露给用户的一致性，还取决于读路径、客户端会话、缓存和 API 设计。不要把协议共识和业务读语义混成一个概念。
六、面试追问与工程边界
面试官可能问 Raft 是否就是 ZAB 的改名。不能这么说。它们有相似思想，但来源、术语和细节不同。Raft 是独立提出的共识算法，目标之一是替代难理解的 Paxos 表述；ZAB 是 ZooKeeper 的协议，围绕 ZooKeeper 的事务、会话和协调语义构建。
还可能问哪个更好。合理回答是看场景：学习和解释通用共识，Raft 更清晰；理解 ZooKeeper 内部一致性，必须讲 ZAB。工程实现好坏不只取决于协议名，还取决于持久化、快照、成员变更、读策略和运维能力。
七、常见误区与追问
这道题不能只背概念，要把「Raft 与 Zab 对比」放回真实分布式系统里解释：参与方是谁、状态怎么流转、失败后怎么恢复，以及它在一致性、性能、可用性之间做了什么取舍。
| 回答层次 | 要讲清的内容 | 容易漏掉的边界 |
|---|---|---|
| 核心结论 | Raft 和 Zab 都是主从日志复制协议，Raft 强调易理解的选举和日志复制，Zab 面向 ZooKeeper 的原子广播和崩溃恢复 | 不要停在名词解释 |
| 流程机制 | Leader 接收写请求 -> 生成有序日志或事务提议 -> 复制到 Follower -> 多数派确认 -> 提交并应用 -> Leader 故障后恢复未完成日志 | 说明触发方、存储方、确认点和兜底 |
| 工程取舍 | ZooKeeper 写请求由 Leader 广播 Proposal，多数 ACK 后 Commit；Raft 由 Leader AppendEntries 多数成功后提交 | 一致性协议用延迟和可用性换确定顺序，不能只背 Paxos/Raft 名词 |
Raft 与 Zab 对比 面试拆解：
1. Leader 接收写请求
2. 生成有序日志或事务提议
3. 复制到 Follower
4. 多数派确认
5. 提交并应用
6. Leader 故障后恢复未完成日志记忆钩子：先说明故障模型和多数派，再拆选主、日志复制、提交、恢复和安全性边界；回答时要紧扣「Raft 与 Zab 对比」这道题，不要把相邻概念混成一段泛泛的分布式套话。
- 误区：Raft 和 Zab 完全一样。 二者目标相近，但术语、恢复流程和工程语境不同。
- 误区：Zab 只负责选主。 Zab 包括崩溃恢复和原子广播，选主只是恢复阶段的一部分。
- 误区：Raft 一定比 Zab 更强。 强弱不是重点，Raft 更易理解，Zab 深度服务 ZooKeeper。
- 追问：共同点是什么？ 都有 Leader、日志顺序、多数派确认和故障恢复。
- 追问：Zab 的 zxid 有什么作用？ 标识事务顺序和 epoch，帮助恢复时判断日志新旧。
- 追问：面试怎么答对比？ 先说共同目标，再按选主、日志复制、提交和应用场景区分。
八、加强记忆
Raft 和 ZAB 的共同点是 Leader 排序、多数派复制、顺序提交、故障恢复。区别是 Raft 是通用共识算法，术语是 term 和 log；ZAB 是 ZooKeeper 原子广播协议，术语是 epoch 和 zxid。回答时按“共同目标、共同机制、不同定位、不同术语、读语义边界”展开，层次会很清楚。