ZAB（ZooKeeper Atomic Broadcast）解决的是：多台 ZooKeeper 服务器怎样对写入顺序达成一致，并在 Leader 崩溃后继续。你不需要先背状态名，先抓住 epoch、事务序号、法定人数和前缀日志四个不变量。
Table of contents
一次写入怎样提交
客户端写入先到 Leader。Leader 为事务分配 ZXID 并广播提案；获得法定人数确认后发布提交，Follower 按相同顺序应用。ZXID 可理解为由 Leader 周期（epoch）和周期内计数组成的事务标识。
读取可由连接到的服务器直接返回，所以默认不等同于“每次都读取最新 Leader 状态”。需要建立顺序边界时，应依据 ZooKeeper API 的一致性保证设计，而不是在客户端睡眠固定时间。
崩溃恢复做什么
新 Leader 必须拥有足够新的历史，并让法定人数成员的日志与之对齐。恢复阶段会补齐应该提交的前缀、丢弃未形成合法提交的分叉，再进入广播阶段。旧 Leader 恢复后不能凭旧 epoch 继续发提案。
三个常见误解：
- 收到 Leader 响应不等于所有副本都已落盘。
- Follower 数量越多，写吞吐不一定越高；一次提交要等待更多网络与磁盘工作。
- 只剩少数节点时拒绝写入是安全策略，不是选举失败的 bug。
用多数派建立直觉
运行实验室的法定人数测试下载：
mvn -Dtest=DistributedMechanismsTest#snowflakeIdsIncreaseAndQuorumRequiresMajority test5 节点集群可容忍 2 个节点不可用，3 个确认可提交。把节点放到故障域时还要考虑机架和可用区：5 个进程挤在同一台宿主机并不等于能抗两台机器故障。
下一步
继续阅读08-07 Paxos、Raft 与复制状态机，把 ZooKeeper 的具体协议提升为通用共识模型。