4. 分布式协调服务：ZooKeeper核心概念与典型应用
好，咱们进入第四章。这一章聊的是分布式系统的“中枢神经”——ZooKeeper。说实话，我最早接触分布式系统时，觉得这东西就是个“注册中心”，后来踩了坑才明白，它的价值远不止于此。
ZooKeeper 解决的核心问题是什么？说白了，就是让一群互不信任的服务器，能达成一致。你想想看，在分布式环境里，网络延迟、机器宕机、消息乱序，这些都是家常便饭。ZooKeeper 就是那个“和事佬”，帮大家协调好状态。
4.1 ZNode：数据模型的核心
ZooKeeper 的数据模型，是一个树形结构。每个节点叫 ZNode。嗯，这里要注意，ZNode 和 Linux 文件系统的节点不太一样——它既能存数据，也能有子节点。
我个人习惯把 ZNode 分成四类：
| 类型 | 特点 | 典型场景 |
|---|---|---|
| 持久节点 | 创建后一直存在，直到主动删除 | 配置信息、服务注册 |
| 临时节点 | 客户端会话结束自动删除 | 服务心跳检测、分布式锁 |
| 持久顺序节点 | 持久节点 + 自动递增序号 | 分布式队列、选举 |
| 临时顺序节点 | 临时节点 + 自动递增序号 | 分布式锁（最常用） |
我在项目中遇到过一个问题：有人把临时节点当持久节点用，结果客户端一断连，数据全丢了。所以，选类型时一定要想清楚——这个节点是跟着会话走，还是永久保留？
4.2 Watcher：事件通知机制
Watcher 是 ZooKeeper 的“消息推送”机制。客户端可以注册一个 Watcher 到某个 ZNode 上，当这个节点发生变化时，ZooKeeper 会主动通知客户端。
这里有个坑，我曾经踩过：Watcher 是一次性的。什么意思？就是触发一次后，它就失效了。如果你需要持续监听，必须在回调里重新注册。
Watcher 的典型流程是这样的：
- 客户端调用
getData()并注册 Watcher - ZooKeeper 服务端记录这个 Watcher
- 当 ZNode 数据变化时，服务端发送通知
- 客户端收到通知，执行回调
- 回调中重新注册 Watcher（这一步容易忘）
4.3 Paxos 与 ZAB 协议
聊到 ZooKeeper，绕不开两个协议：Paxos 和 ZAB。很多人觉得它们是一回事，其实不然。
Paxos 是 Leslie Lamport 提出的共识算法，理论性很强。说实话，我第一次看 Paxos 论文时，差点睡着。它用“提案者”、“接受者”、“学习者”这些角色，描述了一个非常严谨的共识过程。但 Paxos 有个问题——它太抽象了，工程实现起来很复杂。
ZAB（ZooKeeper Atomic Broadcast） 是 ZooKeeper 自己实现的协议。它借鉴了 Paxos 的思想，但做了很多工程优化。ZAB 的核心是“原子广播”——所有写操作都必须经过 Leader，Leader 把写请求广播给所有 Follower，超过半数确认后，才算提交成功。
你想想看，为什么需要半数？因为分布式系统里，网络分区是常态。如果 Leader 挂了，剩下的节点必须能选出一个新 Leader。半数机制保证了：任何两个“多数派”之间，至少有一个公共节点，这样就不会出现“两个 Leader”的情况。
- Paxos 是理论模型，ZAB 是工程实现
- ZAB 专门为 ZooKeeper 设计，支持“崩溃恢复”和“消息广播”两个阶段
- ZAB 保证了“全序广播”——所有消息按顺序执行，不会乱
4.4 典型应用：配置管理
配置管理是 ZooKeeper 最直观的应用。把配置信息存在一个持久节点里，所有客户端监听这个节点。配置变了，客户端自动收到通知。
我建议的做法是这样的：
// 服务端写入配置
zkClient.create("/config/db_url", "jdbc:mysql://...", CreateMode.PERSISTENT);
// 客户端监听配置
zkClient.getData("/config/db_url", new Watcher() {
@Override
public void process(WatchedEvent event) {
if (event.getType() == Event.EventType.NodeDataChanged) {
// 重新读取配置
String newConfig = zkClient.getData("/config/db_url", this, null);
// 更新本地配置
updateLocalConfig(newConfig);
}
}
}, null);
嗯，这里要注意：配置变更时，最好先验证新配置的合法性，再应用。我曾经见过一个事故——运维手抖写了个错误配置，结果所有服务瞬间崩溃。所以，加个“配置校验”环节，很有必要。
4.5 典型应用：分布式锁
分布式锁是 ZooKeeper 的另一个杀手级应用。相比 Redis 的分布式锁，ZooKeeper 的锁更可靠——因为它基于临时顺序节点，客户端挂了锁会自动释放，不会死锁。
实现思路是这样的：
- 所有客户端在同一个锁路径下创建临时顺序节点
- 每个客户端检查自己是不是序号最小的那个
- 如果是，就获得锁
- 如果不是，就监听前一个节点的删除事件
- 前一个节点被删除后，重新检查
这个方案叫“排他锁”，也叫“写锁”。还有一种“读写锁”——读锁可以共享，写锁必须互斥。实现起来稍微复杂一点，但原理类似。
4.6 小结
这一章我们聊了 ZooKeeper 的三个核心概念：ZNode、Watcher、ZAB 协议。也看了两个典型应用：配置管理和分布式锁。
说白了，ZooKeeper 就是分布式系统的“粘合剂”。它不负责业务逻辑，但负责让大家“说好”。我做了这么多年分布式系统，越来越觉得：共识机制是分布式系统的基石。没有 ZooKeeper 这类工具，很多分布式应用根本跑不起来。
下一章，我们会聊分布式消息队列。嗯，那又是另一个精彩的故事了。