第四章 共识案件簿：ZAB、选主、监听、会话与权限

第四章 · 共识案件簿：ZAB、选主、监听、会话与权限

章节摘要：本章是全册的心脏。我们把 ZooKeeper 内部的四大机制当作四个案件逐一审理：ZAB 协议如何让一张写提案全票通过，Leader 倒台后选举如何秒级重启，Watcher 在服务端如何送达又为何只响一次，会话租约如何存续与吊销，外加 ACL 这本访客登记簿。读懂本章，后两章的所有现象都能自行推导。

一条主线

主线上只有一个问题：一纸判决如何做到全庭信服，且法官倒下后判决书一张不丢。 想象你在 3.3 节敲下 client.create().forPath("/lock/n1")。这句话经过 TCP 到达某台服务器，被转交给 Leader；Leader 给它编号、盖章、广播给所有 Follower；过半点头后各庭落卷归档；返回你"创建成功"四个字。这中间发生了几次落盘、几轮确认、哪些环节可能失败——这就是 4.1 节 ZAB 原子广播审理的内容。

但法庭不是永生的。Leader 所在机器掉电的瞬间，全庭进入"法官席位空缺"状态：剩余节点互相摸底、交换选票、推举新主、补齐卷宗——4.2 节的快速选举。而旁听席上的当事人们（客户端）如何第一时间得知"卷宗变了"，靠的是 4.3 节的 Watcher 送达机制；他们自己的出庭资格（会话）如何年检、过期后临时节点如何清算，是 4.4 节；最后，谁有权查阅哪些案卷，由 4.5 节的 ACL 权限体系裁定。四个案件共享同一批底层构件：事务号 zxid、多数派表决、日志与快照。它们不是孤立的知识点，而是同一台机器的四个侧面。

沿途站点

各节在主线上的位置如下，先后关系就是依赖关系：

4.1 ZAB 原子广播：正常运转时的写路径。提案编号、两阶段提交、过半即提交的表决规则，以及崩溃恢复时如何用编号对齐各庭卷宗——持久化机制（日志与快照）也在本节一并交代。

4.2 快速选举：非常时期的权力交接。选票如何构造、如何比较、如何收敛；为什么选举优先比数据新旧、相同才比编号；选举期间全集群为何拒绝对外服务。

4.3 Watcher 送达：一致性通知的形状。注册表存在哪、事件何时生成、为何一次触发即失效、通知与数据变更的先后顺序保证了什么。

4.4 会话租约：出庭资格的存续。会话在服务端如何登记与分桶续租，过期判定的边界，临时节点清算的连锁反应——锁与注册中心的一切"自动回收"都源于此。

4.5 ACL 权限：案卷的访问控制。每节点一张访问表，七种权限位与四种认证 scheme，以及多用户共享集群时的隔离实践。

拐点与结论

本章有两次认知跃迁。第一次在 4.1 与 4.2 之间：多数人以为"提交"意味着所有节点都确认，实际 ZAB 只要求过半——这既解释了写入的高效，也解释了 1.3 节"少数派侧罢工"的由来，还顺带解释了为什么集群规模影响写入延迟。第二次在 4.4：临时节点的自动删除看起来像便利功能，实际是一致性的附属品——会话过期意味着该客户端无法再证明自己活着，若它的登记还留着，选主与锁就会把资源交给一个可能复活的旧身份。把"便利"读成"必要"，你对这套系统的理解就上了一个台阶。

读完本章你应该能：画出一次写请求从客户端到落盘的完整链路并标出多数派确认点；解释 zxid 的结构以及选举时如何用它判断数据新旧；复述 Watcher 一次触发的设计原因；说出会话过期后服务端清算的三件事；为共享集群设计一套最小可用的 ACL 方案。

下一章的接力

机制审理完毕，第五章把它们押上"应用现场"：配置中心、分布式锁、业务选主、服务注册四个判例，每一个都是本章某个机制的直接应用。判例里的每行代码，都值得你回头对照本章找出它背后的机制依据。

收官前补一句对读者的提醒：本章五个案件的深度是不均匀的。ZAB 与选举两案值得精读三遍，它们是所有现象的解释源；Watcher 与会话两案要与第五章判例对照着读，机制与应用互相印证；ACL 一案按需掌握即可，共享集群的读者应精读，独占集群的读者过一遍建立意识。