Paxos 与 ZAB
Paxos 是共识理论的鼻祖，ZAB 是 ZooKeeper 的实现。面试考的是理解脉络和对比，不是 Paxos 的证明细节。
Paxos：共识的理论基石
Basic Paxos 的两阶段（角色：Proposer 提议者、Acceptor 接受者、Learner 学习者）：
阶段一 Prepare: Proposer 发 Prepare(n), 多数 Acceptor 承诺不再接受 < n 的提议
阶段二 Accept: 多数接受后, Proposer 发 Accept(n, value), 多数接受则选定- 多数派（quorum）保证：两个多数派必有交集 → 不会选出不同值
- 活锁问题：两个 Proposer 互相打断（工程上 leader 化解决）
- Multi-Paxos：连续多轮 Paxos（稳定 Leader 后只走 Accept 阶段）
面试深度：能讲清两阶段 + 多数派交集原理 + 活锁即可，不需要证明细节。
Paxos vs Raft
| 维度 | Paxos | Raft |
|---|---|---|
| 理解难度 | 高（论文难读） | 低（分解子问题） |
| 选举 | 隐式（多 Proposer） | 显式 Leader 选举 |
| 日志 | 论文未完整规定 | 完整日志复制协议 |
| 工程实现 | 少（Chubby） | 多（etcd/Consul） |
面试话术：理论价值 Paxos 更高，工程实践 Raft 胜出（可理解性决定可实现性）。两者数学本质相同（多数派共识）。
ZAB：ZooKeeper 的原子广播
- ZAB（ZooKeeper Atomic Broadcast）：ZK 的共识协议，类似 Raft 但独立发展
- 核心：Leader 选举 + 原子广播（写请求全走 Leader，多数确认）
- 与 Raft 关系：同为“领导 + 多数派 + 日志”家族，独立设计
ZooKeeper 的应用
| 能力 | 机制 | 应用 |
|---|---|---|
| 分布式锁 | 临时顺序节点 | 任务调度（见分布式锁篇对比） |
| 配置管理 | watch 通知 | 配置中心 |
| 服务发现 | 临时节点 + 监听 | 注册中心 |
| 元数据存储 | 树形节点 | 早期 Kafka/HBase |
ZK 的特点：CP 系统（分区时不可用，见 CAP 篇）；写性能有限（单 Leader 广播），读可水平扩展。
面试追问
- Paxos 两阶段？ Prepare（承诺多数）+ Accept（接受多数）。多数派交集保证一致性
- Paxos 的活锁？ 多 Proposer 互相打断。工程上选 Leader 解决
- Raft 和 Paxos？ 理论同源（多数派共识），Raft 分解子问题更可实现。工程选 Raft
- ZAB 是什么？ ZK 的原子广播协议：Leader + 多数确认。独立于 Raft 设计
- ZK 什么时候用？ 强一致元数据、分布式锁、配置。写性能有限，读可扩展