一、为什么需要协调服务

单机时代不存在的问题，到了分布式时代全冒出来了：

二、数据模型：ZNode 与四种节点类型

ZooKeeper 的数据模型是一棵树，每个节点叫 ZNode。和文件系统不同的是：节点既是目录也是文件——可以存数据（默认上限 1MB，jute.maxbuffer），也可以有子节点。

2.1 四种节点类型（必须分清）

临时节点是 ZooKeeper 的”杀手锏”：节点的生命周期与会话绑定。机器宕机 → 会话超时 → 节点自动消失 → 其他机器立刻感知。不需要任何应用层的”心跳 + 超时清理”代码， coordination 里最难缠的”僵尸节点”问题被底层收编了。

2.2 Stat 元数据与版本号

每个 ZNode 携带一组 Stat 信息，最重要的是三个版本号（CAS 乐观锁的抓手）：

1
2
3
4
5
6
7
8
9
10
11

[zk: localhost:2181(CONNECTED) 3] stat /config/db-url
cZxid = 0x100000002        # 创建该节点的事务 zxid
ctime = Thu Oct 23 10:00:00 CST 2026
mZxid = 0x100000005        # 最后一次修改的 zxid
mtime = Thu Oct 23 10:05:00 CST 2026
version = 2                # 数据版本号（每次 setData +1）
cversion = 0               # 子节点版本号
aversion = 0               # ACL 版本号
ephemeralOwner = 0x0       # 非 0 表示临时节点，值为所属会话 id
dataLength = 28
numChildren = 0

利用 version 可以实现原子的”检查再设”：

1
2
3

# 只有当 version 仍是 2 时才更新，避免覆盖别人的修改
set /config/db-url "jdbc:mysql://new-host:3306/db" 2
# version 已变则抛 BadVersionException

三、会话（Session）与心跳

• 客户端连上后创建会话，会话有超时时间，由客户端请求值和服务端 [2×tickTime, 20×tickTime] 协商取交集（tickTime 默认 2000ms，即 4s~40s）；
• 会话期内客户端必须在超时前收到服务端的 PING 心跳（客户端 SDK 自动发），否则会话过期；
• 会话过期是 Leader 判定的（会话由 Leader 跟踪、随 ZAB 广播），Follower 无法单独判死一个会话——这保证了所有服务器对”某机器还活不活着”的看法一致；
• 会话过期后，该会话创建的所有临时节点被删除，注册的 Watch 触发。

四、Watch 机制：一次性触发的订阅通知

Watch 是 ZooKeeper 提供的”变更推送”原语，四个关键语义：

1. 一次性触发：Watch 触发一次后即失效，想继续监听必须重新注册（Curator 的 NodeCache/TreeCache 帮你自动重注册，业务代码别手写）；
2. 轻量：通知里只有”事件类型 + 路径”，不含变更后的数据——收到通知后要自己再 get 一次（getData(watch=true)）；
3. 顺序性保证：客户端先看到 Watch 通知，再看到被通知的新数据，且通知严格按事件发生的先后顺序送达，不会乱序；
4. 异步：注册时立即返回，事件由独立的线程回调。

1
2
3
4
5
6
7

// 原生 API 的三个 Watch 注册点：getData / exists / getChildren
zk.getData("/config/db-url", event -> {
    if (event.getType() == NodeDataChanged) {
        byte[] latest = zk.getData("/config/db-url", this);  // 重新注册（死循环范式）
        refresh(latest);
    }
}, null);

4.1 羊群效应（Herd Effect）：Watch 最经典的坑

朴素做法：N 个客户端全部 Watch 同一个 /lock 节点。锁释放（节点删除）时，N 个客户端全部被唤醒去抢，抢完再注册回来——高并发下这叫惊群，通知风暴直接打爆服务端。

正确姿势（也是分布式锁的标准实现）：

1
2
3

/lock/seq-0000000001   ← 客户端 A：序号最小，获得锁
/lock/seq-0000000002   ← 客户端 B：只 Watch seq-0000000001
/lock/seq-0000000003   ← 客户端 C：只 Watch seq-0000000002

每个客户端只创建自己的临时顺序节点，只 Watch 前一个节点。A 释放后只唤醒 B，B 变成最小者拿锁——唤醒次数从 O(N) 降到 O(1)。

五、集群架构与读写流程

5.1 三种角色

Observer 的价值：3 台集群的写投票能力是固定的（过半 = 2），加 Follower 只会让每次写的投票开销变大；要读扩容，加 Observer，别加 Follower。

5.2 写请求的完整链路（过半提交）

1
2
3
4
5
6
7

Client → (任意服务器)
   └─ 非 Leader：转发给 Leader
        Leader：给写请求分配全局单调的 zxid，放入每个 Follower 的 FIFO 队列
        ├─ PROPOSAL（提议）→ 所有 Follower
        ├─ Follower 落事务日志 → 回 ACK
        ├─ 过半 ACK → Leader 发 COMMIT
        └─ 各节点 apply，客户端收到响应

注意两点：

• 写是”过半成功即算成功”，不是全部成功——剩余节点靠 ZAB 的恢复机制最终追平；
• 读是”读本地”，Follower 直接返回自己内存里的数据——因此读到旧数据是可能的（Follower 短暂落后）。要求”读到我刚写的数据”时，先调 sync(path) 再读。

六、ZAB 协议：崩溃恢复与消息广播

ZAB（ZooKeeper Atomic Broadcast）是专门为 ZooKeeper 设计的原子广播协议，两个模式：

6.1 消息广播（Leader 正常时）

形似 2PC，但砍掉了回滚阶段：

所有 Proposal 带全局单调递增的 zxid，按 zxid 顺序广播、按 zxid 顺序提交——这就是”全序”（Total Order）：所有服务器以完全相同的顺序看到每一条写操作。这是分布式锁、选主能做对的前提。

zxid 是 64 位：高 32 位是 epoch（任期），低 32 位是计数器。每次选出新 Leader，epoch + 1。这样老 Leader 若”复活”（比如长时间 GC 后恢复），它拿的旧 epoch zxid 一定小于新 epoch，其未提交的提议会被丢弃——从机制上防止了”老 Leader 的幽灵写”。

6.2 崩溃恢复（Leader 挂了/失联时）

恢复分两步：

1. 选举（FastLeaderElection）：每个投票者比较候选者的 (peerEpoch, zxid, myid) 字典序——zxid 最新的优先，其次 myid 大的优先，过半票即当选。直觉：选”数据最新”的机器当 Leader，丢失的数据最少；
2. 数据同步：新 Leader 把自己已提交的 Proposal 同步给所有 Follower；同时丢弃（截断）旧 epoch 中未过半提交的 Proposal。同步完成（过半达成一致）后才切换到广播模式，开始服务。

ZAB 承诺的两个不变式：

• 已提交的不会丢：只要过半节点存活，任何已过半提交的写入在恢复后必然存在；
• 未提交的不会冒出来：只有被过半确认的数据才可能成为最终提交值。

七、典型应用：锁、选主、配置中心怎么落地

7.1 分布式锁：别手写，理解 Curator 的实现

直接手写原生 API 极易踩坑（Watch 丢失、羊群、连接抖动后锁状态未知）。生产用 Curator 的 InterProcessMutex，它内部就是第四节的”临时顺序节点 + Watch 前驱”方案：

1
2
3
4
5
6
7
8
9
10
11
12

InterProcessMutex lock = new InterProcessMutex(client, "/locks/order-submit");
try {
    if (lock.acquire(5, TimeUnit.SECONDS)) {      // 支持超时，避免死等
        try {
            doBusiness();                          // 临界区
        } finally {
            lock.release();                        // finally 必释放
        }
    } else {
        throw new TimeoutException("acquire lock timeout");
    }
} 

ZooKeeper 锁 vs Redis 锁，一句话选型：

7.2 Master 选举与配置中心

• 选主：Curator LeaderLatch（一组进程抢同一个 /master 下的临时顺序节点，最小者当选）或 LeaderSelector（当选后可主动让权，实现轮值）。选主与业务解耦的关键是：监听”我是否还持有 leadership”的回调，失去时立刻暂停写操作——会话抖动时节点可能短暂易主；
• 配置中心：配置写 ZNode，所有实例 Watch 它。变更推送毫秒级到达，配合 Stat 的 version 做灰度比对。早期 Dubbo、Canal 的配置下发就是这么做的；
• 服务注册发现：实例上线 create -e /providers/instance-xxx，下线自动消失；调用方 getChildren(watch=true) 监听列表变化。（注意：ZooKeeper 做服务发现是 CP 的——网络分区时宁可返回不可用列表也不返回旧列表，对”可用性优先”的服务注册场景，Eureka/Nacos 这类 AP 方案往往更合适。）

八、ZooKeeper vs etcd vs Consul

选型直觉：大数据生态内，跟着组件走用 ZooKeeper；K8s 世界用 etcd（别自己再造）；服务网格/多机房场景看 Consul。 新项目自建协调层时，除非生态绑定，etcd 的运维成本通常更低。

九、生产避坑清单

1. 集群节点数取奇数（3 或 5）：过半写投票需要 (N+1)/2 台存活；5 台能容忍 2 台故障，但每次写要 4 台 ACK——除非对可用性要求极高，3 台起步就够；
2. 事务日志单独一块高性能盘：每个写请求都要刷事务日志，日志盘 IO 抖动 = 集群整体写延迟飙升，千万别和数据快照/应用混盘，优先 SSD；
3. JVM 堆别贪大，4~8G 足够：ZooKeeper 数据全在内存，但堆太大会放大 Full GC 停顿——GC 停顿超过会话超时会让 Leader 误判大量会话死亡、临时节点雪崩甚至触发无谓重选举；
4. 别把 ZK 当数据库：单 ZNode 默认 1MB 上限，写吞吐几千 TPS。大 JSON 配置、高频指标一律走数据库/配置中心，ZK 只放”必须全局一致的少量元数据”；
5. Watch 必须处理重注册：一次性触发 + 网络断线期间的事件不会补发——手写 Watch 忘了重注册 = 丢失一次变更。用 Curator Cache 兜底；
6. 羊群效应自查：凡是”N 个客户端 Watch 同一个节点”的代码都值得警惕，改成 Watch 自己的前驱节点；
7. sessionTimeout 与 GC/网络对齐：太短 → 临时节点抖动、服务列表频繁刷新；太长 → 故障机器的资源（锁、注册）迟迟不释放；
8. Observer 用于读扩容与跨机房：跨机房部署时把异地节点设为 Observer，避免异地 Follower 的投票延迟拖慢全局写；
9. 开 autopurge 防磁盘膨胀：快照与事务日志默认不清理（autopurge.purgeInterval=0），生产必须开启（如每 24h 清一次、保留 3 份快照）；
10. 排障三板斧：zkServer.sh status 看角色、zkCli.sh -server host:2181 stat/ls 看数据与会话（ephemeralOwner）、dump 列出全部会话与临时节点——临时节点异常堆积时先查对应会话为何没断干净。

系列阅读：Kafka 核心原理与实战（数据怎么流起来）→ HBase 核心原理与实战（海量数据怎么存）→ 本文（集群之间怎么协调）。Kafka 与 HBase 的元数据/选主正是靠本文的这套机制稳稳落地——大数据”采-存-算-协”四层拼图就此补全。