第五章 判例集：配置、锁、选主与注册发现

第五章 · 判例集：配置、锁、选主与注册发现

章节摘要：本章把第四章的机制押上应用现场，审理四个经典判例：配置中心如何用监听实现动态下发，分布式锁如何靠临时顺序节点排队叫号，业务集群如何自己选主，服务注册与发现如何用临时节点维护活着的实例名单。每个判例都给出背景、完整实现、结果验证与变式。

一条主线

四个判例背后是同一个句式：把一份需要共识的状态放到 ZNode 上，把"变化"交给 Watcher 通知，把"存活"绑定到会话。 配置中心放的是配置值，分布式锁放的是排队序号，业务选主放的是候选人登记，注册中心放的是实例名单。区别只在节点类型与监听方式的组合——这正是第四章的价值：判例不是要背的模式，而是机制组合的必然结果。

本章所有代码基于 3.3 节的 Curator 底座，重点不在 API 而在设计取舍：为什么锁要用顺序节点而不是抢同一个节点，为什么监听前序而不是监听全体，为什么注册用临时节点而配置用持久节点。每个"为什么"都能回溯到第四章的某个案件。

沿途站点

判例一，5.1 节 配置管理。最小判例：持久节点存配置，NodeCache 监听变化，回调刷新应用内配置对象。重点讲"通知是信号不是数据"如何影响回调设计，以及版本号条件更新怎么防并发覆盖。

判例二，5.2 节 分布式锁。全册含金量最高的判例：临时顺序节点排号、只监听前序节点防羊群、会话死锁自动放行。手写一版迷你锁再对照 Curator 的 InterProcessMutex，理解封装到底补了什么。

判例三，5.3 节 业务选主。不是 ZooKeeper 自己的选举，而是你的业务集群用 ZNode 选出"谁来干活"：临时节点占位加监听，主挂自动补位。对比 Curator 的 LeaderLatch 与 LeaderSelector 两种风格。

判例四，5.4 节 命名服务与分布式队列。命名服务：用顺序节点生成全局唯一 ID、用临时节点维护实例名单，TreeCache 全量订阅。分布式队列：序号即队位，消费即删除，并说清它为什么只适合轻量任务。

拐点与结论

判例集最容易发生的认知偏差是"背配方"。本章刻意让每个判例在关键处停一下，先问"换个设计会怎样"：锁若都监听同一个节点会怎样——羊群效应；注册若用持久节点会怎样——死实例永远占位；配置回调里做重活会怎样——3.2 节的事件线程排队。把这些问题在代码里找到答案，判例才真正属于你。

读完本章你应该能：独立实现一个带监听刷新的配置中心客户端；讲清 InterProcessMutex 背后的排队模型并手写简化版；为业务集群选择 LeaderLatch 或 LeaderSelector 并说明理由；搭一套基于临时节点与 TreeCache 的服务注册发现原型；判断哪些任务适合 ZK 队列、哪些该交给专业消息系统。

下一章的接力

判例都是"做成"的样子，下一章看"翻车"的样子：脑裂、羊群效应、不一致、会话抖动。有意思的是，第六章每个冤案都能在第五章找到对应的判例原型——故障往往是判例在某处用错了组合。

本章结构速览

四个判例与第四章机制的对应关系一图收拢，每个判例都能指出它踩在哪些机制之上：

判例章的读法与机制章不同：机制章求深，判例章求熟。建议每个判例都做到三件事——把代码跑通、把验证命令跑一遍、把"变式"小节的问题口答一遍。尤其变式，它们是真实评审会上最常被问到的问题：配置并发改了怎么办、锁的临界区比租约长怎么办、选主补位要多久、队列为什么不适合大流量。答案都能从机制推导，但只有在开口复述的那一刻，推导才真正属于你。

另外，四个判例之间存在隐含的工程次序，值得点破：配置管理是几乎所有团队第一个上手的用法（风险最低、收益立现），锁与选主需要先把 4.4 节的会话机制吃透再上线，注册中心的体量治理则要等羊群效应真正出现后再动（6.2 节）。按这个次序推进，每个判例都踩在前一个的验证之上。