🧩 一、ZAB 是什么
ZAB 保证：所有正常节点以相同顺序应用事务（Proposal），且在 Leader 崩溃后能恢复一致。它面向的是"一个 Leader 提出、Follower 按顺序确认"的主从模型，比通用 Paxos 更贴合 ZK 实际使用方式。
一句话：ZAB = 崩溃恢复（选新 Leader + 数据对齐）+ 原子广播（Leader 把事务按 zxid 顺序发给 Follower，多数派确认后提交）。
🎭 二、三种角色
Leader
唯一的事务发起者，负责广播提案、收集 ACK。
Follower
接收提案、投票、参与选举；参与半数确认。
Observer
只读副本，不参与投票，用于横向扩展读能力。
🔄 三、两种模式
崩溃恢复（Recovery）
Leader 挂掉或集群启动时使用。通过选举选出数据最全（zxid 最大）的 Follower 当新 Leader，并让所有节点数据对齐到新 Leader，保证"已提交的不丢、未提交的不生效"。
消息广播（Broadcast）
正常运行时，Leader 把写请求转成带 zxid 的事务提案，发给所有 Follower，收到半数 ACK 后提交并通知大家应用。
📡 四、消息广播流程（类似 2PC 但只要求半数）
zxid 是关键：64 位，高 32 位是 epoch（每次新 Leader 递增），低 32 位是计数器。zxid 全局单调，用于排序与选举比较。
⚖️ 五、ZAB vs Paxos / Raft
| 维度 | ZAB | Paxos | Raft |
|---|---|---|---|
| 定位 | ZK 专用 | 通用共识理论 | 通用共识（工程化） |
| 模型 | 主从 + 顺序广播 | 角色可重叠 | 强主 + 日志复制 |
| 顺序 | 严格按 zxid 顺序 | 单值达成 | 按日志索引顺序 |
| 关系 | 三者都能容忍少数故障；ZAB/Raft 可视为"为顺序日志定制的 Multi-Paxos 变体" | ||
🎯 六、面试高频追问
ZAB 和 Paxos 是一回事吗？
不是同一协议，但目标相同（容错共识）。ZAB 专为"主从 + 顺序事务广播"设计，更强调事务的顺序性与崩溃恢复；Paxos 更通用抽象。
崩溃恢复怎么保证不丢已提交数据？
选举时只让"拥有最高 zxid（数据最全）"的节点当 Leader，且恢复阶段会同步补齐缺失的事务，确保已被半数确认的事务不会丢失。
Observer 有什么用？
Observer 不加进投票法定人数，因此增删 Observer 不影响"半数"门槛，可在不影响写性能的前提下扩展读吞吐。
延伸阅读：Paxos · Raft 日志复制 · ZooKeeper 详解