ZooKeeper 是 Apache 开源的分布式协调服务框架，最初是 Yahoo 为 Hadoop 生态开发的子项目，后来独立成为顶级项目。它提供了一套简单的原语（创建节点、删除节点、监听节点变化、获取子节点列表等），让分布式应用可以在这些原语之上构建出分布式锁、服务注册与发现、配置中心、集群选举等高阶协调功能。ZooKeeper 的核心设计目标是 CP 模型（一致性和分区容错性），通过 ZAB（ZooKeeper Atomic Broadcast）协议保证集群节点之间的数据强一致性，适合作为分布式系统的"协调中枢"而非数据存储。

一、核心架构与集群角色

ZooKeeper 采用 Leader-Follower 架构，集群中每个节点称为一个 Server，根据角色分为三类：

为什么集群推荐奇数台：ZooKeeper 的写操作需要过半（Quorum）节点确认才能提交。3 台节点容忍 1 台宕机（2/3 > 50%），4 台节点同样只能容忍 1 台宕机（3/4 > 50%），但 4 台比 3 台多了一台的成本和多一次 Proposal 广播。因此 3、5、7 等奇数是性价比最优的选择。

集群通信架构：

                     ┌─────────────┐
                     │   Client    │
                     └──────┬──────┘
                            │ (读写请求)
              ┌─────────────┼─────────────┐
              ▼             ▼             ▼
        ┌──────────┐ ┌──────────┐ ┌──────────┐
        │  Leader  │◄├─►│Follower │◄├─►│Follower │
        └────┬─────┘ └──────────┘ └──────────┘
             │ (事务 Proposal 广播 + 过半 Ack)
             │
             ▼
        ┌──────────┐
        │ Observer │  (只接收同步数据，不参与投票)
        └──────────┘

• 每个 Server 之间通过 TCP 长连接维持心跳和数据同步（底层基于 Netty 实现通信）
• 客户端与 Server 之间也通过 TCP 长连接维护 Session，心跳超时则 Session 过期

二、数据模型与 ZNode

ZooKeeper 的数据模型类似于文件系统，以树形层级命名空间组织，每个节点称为一个 ZNode。ZNode 既可以存储数据（默认上限 1MB），也可以拥有子节点，兼具"目录"和"文件"的双重特性。

ZNode 的四类模式：

ZNode 的核心属性：

每个 ZNode 在内存中维护一个 Stat 结构体，包含以下关键信息：

乐观锁（CAS）操作示例：

// 读取当前数据，获取版本号
Stat stat = new Stat();
byte[] data = zk.getData("/config", false, stat);
int currentVersion = stat.getVersion();

// 更新时传入期望的版本号，如果版本号已变则更新失败
try {
    zk.setData("/config", newData, currentVersion);
} catch (KeeperException.BadVersionException e) {
    // 版本冲突，说明其他客户端已修改过，需重新读取后重试
    // 这正是乐观锁的核心语义
}

三、ZAB 协议与数据一致性

ZooKeeper 通过 ZAB（ZooKeeper Atomic Broadcast）协议 保证集群内所有节点的数据强一致性。ZAB 是 ZooKeeper 自研的原子广播协议，与 Paxos 和 Raft 有相似的设计思想，但更聚焦于 ZK 自身的场景需求。

ZAB 协议的两种工作模式：

1. 崩溃恢复模式（Crash Recovery）

当集群启动时或 Leader 崩溃后进入此模式，目的是选举出一个新的 Leader，并由该 Leader 将集群内所有节点的数据同步到一致状态。核心步骤：

• Leader 选举：各节点投票选择包含最新事务 ID（Zxid）的节点作为 Leader。Zxid 是一个 64 位的长整型，高 32 位是 Epoch（任期号），低 32 位是事务计数器。拥有最大 Zxid 的节点意味着拥有最新的数据，优先成为 Leader。
• 数据同步：新 Leader 确定后，各 Follower 与 Leader 进行数据比对，Leader 将差异事务发送给落后的 Follower，确保所有节点数据一致。同步完成后，集群进入消息广播模式。

2. 消息广播模式（Message Broadcast）

集群正常运行时的模式，处理客户端的写请求。流程类似于两阶段提交（2PC），但做了简化优化：

Client ──write──► Leader ──Proposal──► Follower 1 ──Ack──► Leader
                         ──Proposal──► Follower 2 ──Ack──► Leader
                         ──Proposal──► Follower 3 ──Ack──► Leader

Leader 收到超过半数的 Ack 后：Commit ──► 所有 Follower ──► 各自应用到内存数据库
Leader 自身也应用事务后：响应 Client 写成功

ZAB vs Raft 的核心差异：ZAB 的 Leader 选举优先选择 Zxid 最大的节点（数据最新原则），而 Raft 则通过 Term + 日志长度综合判断。ZAB 的 Commit 消息是 Leader 显式发送的，而 Raft 的 Commit 判断依赖于日志匹配的前置条件。

Zxid 的设计细节：

Zxid（64 位）是 ZooKeeper 事务一致性的核心载体：

┌──────────────┬──────────────────┐
│  高 32 位    │     低 32 位     │
│   Epoch      │   事务计数器     │
│  (任期编号)   │   (自增计数器)   │
└──────────────┴──────────────────┘

• Epoch（任期）：每次 Leader 选举产生新的 Epoch 值（+1），用于区分不同 Leader 任期的事务，也用于 Follower 判断 Leader 是否已变更
• 事务计数器：同一 Epoch 内每产生一个事务自增 1，保证事务在全局范围内的有序性

四、Leader 选举机制

Leader 选举是 ZooKeeper 高可用的核心。当集群启动或 Leader 宕机时，所有 Follower 进入 LOOKING 状态并开始选举。

选举算法核心规则（按优先级排序）：

1. 先比较 Zxid：Zxid 最大的节点优先成为 Leader（数据最新原则，避免数据回滚）
2. Zxid 相同时比较 myid：myid 是每个节点的集群唯一编号（配置在 zoo.cfg 的 myid 文件中），myid 大的优先（用于打破平局）

选举过程（以 3 节点为例，假设 Server1 先启动）：

选举触发的三个场景：

1. 集群初始化启动：所有节点都是 LOOKING 状态，通过选举产生第一个 Leader
2. Leader 宕机：Follower 与 Leader 的心跳超时，Follower 进入 LOOKING 状态发起新一轮选举
3. Follower 宕机恢复后：恢复的 Follower 可能拥有比当前 Leader 更新的 Zxid（极端情况），此时可能触发重新选举

五、Session 与会话管理

ZooKeeper 客户端与 Server 之间的交互基于 Session（会话） 机制。客户端连接到集群时，由 Server 分配一个全局唯一的 SessionID，并在整个 Session 生命周期内维持。

Session 的核心参数：

Session 状态机：

CONNECTING ──► CONNECTED ──► EXPIRED
    │                           ▲
    └──── DISCONNECTED ─────────┘
         (重连后恢复为 CONNECTED)

• CONNECTING：客户端正在尝试连接，初始状态
• CONNECTED：连接成功，Session 建立，客户端可以读/写/注册 Watcher
• DISCONNECTED：客户端与 Server 断开（网络抖动、Server 宕机），客户端自动重连其他 Server。在 Session 超时窗口内重连成功则恢复为 CONNECTED，所有 Watcher 和临时节点仍然有效
• EXPIRED：断开超过 Session 超时时间仍未重连成功，Session 永久失效。该 Session 关联的所有临时节点被删除、所有 Watcher 被清理

关键设计：客户端断开重连到另一个 Server 时，只要在 Session 超时窗口内，其 SessionID 依然有效，临时节点不会丢失，Watcher 也会被重新注册。这得益于 ZooKeeper 服务端维护的全局 Session 管理机制，不会因为连接到不同的 Server 而丢失状态。

六、Watcher 监听机制

Watcher（观察者/监听器）是 ZooKeeper 实现事件驱动架构的核心机制。客户端可以对 ZNode 注册 Watcher，当 ZNode 发生指定类型的变化时，Server 会向客户端发送事件通知。

Watcher 的核心特性：

1. 一次性触发（One-time Trigger）：Watcher 被触发一次后自动失效。如果需要持续监听，客户端收到通知后需主动重新注册。这个设计简化了 Server 的 Watcher 管理，避免长时间未清理的僵尸 Watcher 堆积。
2. 先通知后数据：Server 先将 Watcher 事件发送给客户端，再处理实际的数据变更。客户端收到通知后重新读取数据时，一定能看到最新值。
3. 顺序性保证：同一个客户端注册的多个 Watcher，其触发顺序严格按照对应 ZNode 的变更顺序执行。如果客户端同时监听了 /config 的 data 变更和 child 变更，触发顺序与实际操作顺序一致。

Watcher 的触发条件：

注意区分：getData 监听的是节点自身数据变化（setData），getChildren 监听的是子节点列表变化（增删子节点）。子节点自身的数据修改不会触发父节点的 getChildren Watcher，这是容易混淆的地方。

Watcher 事件类型：

七、典型应用场景与实战

ZooKeeper 本身提供的是底层原语，真正的业务价值在于基于这些原语构建的分布式协调方案。

1. 分布式锁

利用临时顺序节点实现公平锁（排队锁），是 ZooKeeper 最经典的应用之一：

• 原理：所有竞争者在同一个锁节点下创建临时顺序子节点，序号最小的节点持有锁。后续节点监听它前一个节点的删除事件，从而实现排队等待和锁释放通知。
• 优势：天然支持公平锁、自动释放（Session 断开则临时节点自动删除）、无死锁风险
• 劣势：每次加锁/释放都需要两次 ZooKeeper 操作，性能不如 Redis 分布式锁，但可靠性更高

// 基于 Curator 框架的分布式锁（推荐直接使用 Curator，不要手写原生 ZK API）
InterProcessMutex lock = new InterProcessMutex(client, "/locks/myLock");
if (lock.acquire(10, TimeUnit.SECONDS)) {
    try {
        // 执行业务逻辑
    } finally {
        lock.release();
    }
}

2. 服务注册与发现

Dubbo 早期版本默认使用 ZooKeeper 作为注册中心，其实现原理如下：

• 服务注册：服务提供者启动时，在 /dubbo/com.xxx.Service/providers 下创建临时节点，节点数据为服务地址（IP:Port）。临时节点的特性保证了提供者宕机后注册信息自动清除。
• 服务发现：服务消费者订阅 /dubbo/com.xxx.Service/providers，通过 getChildren + Watcher 获取提供者列表并监听变化，提供者上下线时 Watcher 触发，消费者拉取最新列表。
• 相比 Nacos/Eureka 的差异：ZK 侧重强一致性（CP），适合对一致性要求高的场景；Nacos/Eureka 侧重可用性（AP），适合大规模微服务场景。ZK 在大量临时节点频繁变动时，Watcher 风暴可能成为性能瓶颈。

3. 配置中心

利用持久节点 + Watcher 实现配置热更新：

• 配置存储：每个配置项对应一个 ZNode，如 /config/db.url、/config/db.pool.size
• 配置推送：应用启动时通过 getData 读取配置并注册 Watcher
• 配置更新：管理员修改 ZNode 数据后，所有监听该节点的应用客户端收到 NodeDataChanged 事件，重新拉取最新配置并应用到运行中的系统
• 局限性：ZK 不适合存储大容量配置（单个 ZNode 限制 1MB），且大量 Watcher 的管理开销较高。生产环境通常用于少量核心配置（如开关、阈值），大规模配置管理建议使用 Nacos 或 Apollo

4. Master 选举

在分布式任务调度场景中，需要确保同一时刻只有一个 Master 执行调度（避免重复调度同一批任务）：

• 所有候选者尝试在 /election/master 创建临时节点
• 创建成功者成为 Master，其余候选者在 /election/master 上注册 exists Watcher
• Master 宕机 → Session 断开 → 临时节点自动删除 → 所有候选者收到 NodeDeleted 事件 → 新一轮争抢
• 缺点：存在"惊群效应"（Herd Effect）——所有候选者同时收到通知并同时争抢。可以通过临时顺序节点优化（每个候选者只监听它前一个节点，形成链式唤醒）

5. 分布式 Barrier（栅栏）

协调多个分布式进程在某个节点集合齐后再同时开始执行：

• 在 /barrier 下创建持久节点，所有进程在该节点下注册 getChildren Watcher
• 每个进程到达 Barrier 后，在 /barrier 下创建临时子节点
• 当子节点数量达到预设阈值时，所有进程的 Watcher 被触发，同时开始执行

八、Apache Curator——ZooKeeper 的标准客户端

Netflix 开源的 Curator 是 ZooKeeper 的实际标准客户端库，已经捐献给 Apache 基金会。原生的 ZooKeeper API 存在以下问题，而 Curator 全部解决了：

推荐的 RetryPolicy 配置：

RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3);
// 参数：baseSleepTimeMs=1000（初始重试间隔 1 秒）, maxRetries=3

CuratorFramework client = CuratorFrameworkFactory.builder()
    .connectString("zk1:2181,zk2:2181,zk3:2181")
    .sessionTimeoutMs(40000)      // Session 超时 40 秒
    .connectionTimeoutMs(15000)   // 连接超时 15 秒
    .retryPolicy(retryPolicy)
    .namespace("myapp")           // 业务命名空间隔离
    .build();

client.start();
client.blockUntilConnected();     // 阻塞等待连接成功

九、生产环境配置与调优

zoo.cfg 核心配置项：

JVM 调优建议：

• 堆内存设置：ZooKeeper 将所有 ZNode 数据缓存在内存中（内存数据库），堆内存大小根据 ZNode 数量和单节点数据量估算。通常 4GB ~ 8GB 可满足绝大多数场景。
• GC 策略：推荐使用 G1GC（-XX:+UseG1GC），减少 Full GC 的停顿时间。ZooKeeper 的 Session 超时机制对 GC 停顿极为敏感——长时间的 GC 停顿可能导致所有客户端 Session 超时并断开，引发"雪崩"。
• 关键 JVM 参数：

  -Xms4G -Xmx4G                     // 堆内存固定 4G，避免动态扩容
  -XX:+UseG1GC                       // 使用 G1 垃圾回收器
  -XX:MaxGCPauseMillis=200           // 目标最大 GC 停顿 200ms
  -XX:+DisableExplicitGC             // 禁用显式 System.gc() 调用
  -Xlog:gc*:file=/data/zk/gc.log     // GC 日志输出
  

磁盘与 IO 优化：

• 事务日志目录（dataLogDir）必须使用 SSD：ZooKeeper 的事务日志是同步顺序写（每个写请求都要 fsync 落盘后才返回 Ack），硬盘的 IOPS 直接决定了写性能的上限
• 快照目录（dataDir）与事务日志目录分离到不同物理磁盘，避免 IO 争抢
• 定期清理快照和事务日志，防止磁盘写满导致整个集群挂掉

十、常见问题与解决方案

1. Session 超时导致临时节点批量丢失（雪崩）

• 现象：长时间的 GC 停顿或网络分区导致大量客户端 Session 同时超时，所有关联的临时节点被集中删除，进而触发大量 Watcher 事件通知，造成集群负载飙升甚至崩溃。
• 原因：客户端 JVM GC 停顿时间 > Session 超时时间，或者网络故障超过超时窗口。
• 解决：合理设置 Session 超时时间（如 30~60 秒），避免过短；客户端 JVM 使用 G1GC 控制停顿时间；不要将超时时间设得太短来追求故障恢复速度。

2. "惊群效应"（Herd Effect）

• 现象：一个 ZNode 变化后，所有注册在该节点上的 Watcher 的客户端同时收到通知，同时发起操作（如重读数据、争抢锁），造成瞬时压力峰值。
• 解决：使用临时顺序节点 + 链式监听替代全局 Watcher。每个竞争者只监听前一个节点的变化，而非监听同一个父节点。例如分布式锁场景下 100 个竞争者只触发 1 次事件（而非 100 次）。

3. ZNode 过多导致内存压力

• 现象：大量临时顺序节点（如分布式锁的排队节点）长期未清理，ZNode 数量膨胀，内存占用持续增长。
• 解决：临时节点依赖 Session 自动清理，确保锁使用完毕后主动释放（release()）；持久节点需设计 TTL 或定期清理任务；监控 ZNode 总数和内存使用趋势。

4. 数据不一致（Follower 读到旧数据）

• 现象：客户端从 Follower 读到的数据与 Leader 不一致。
• 原因：ZooKeeper 保证的是顺序一致性而非线性一致性。写操作必须经过 Leader，但读操作可以直接从 Follower 本地内存返回——如果 Follower 尚未收到并应用 Leader 的最新 Commit，客户端可能读到旧数据。
• 解决：如果业务需要读到最新写入的数据（Read-Your-Writes），在读请求前调用 sync() 方法强制 Follower 与 Leader 同步到最新状态。注意 sync() 是异步操作，需要时间等待同步完成。

5. 磁盘写满导致集群不可用

• 现象：事务日志和快照文件持续增长，磁盘写满后 ZooKeeper 无法写入新事务，集群整体不可写。
• 解决：启用 autopurge.snapRetainCount 和 autopurge.purgeInterval 自动清理；设置磁盘空间监控告警（如使用率 > 80% 告警）；事务日志和快照目录使用专用磁盘分区。

6. "脑裂"（Split-Brain）

• 现象：网络分区导致集群分裂为两个子集群，各自选出一个 Leader，产生两个同时接受写入的 Leader。
• 解决：ZooKeeper 通过过半 Quorum 机制天然避免脑裂——一个分区只有包含超过半数的节点才能选举出 Leader。因此 3 节点集群网络分区为 2+1 时，只有 2 节点的分区能选举 Leader，1 节点分区无法单独选举。这也是推荐奇数节点的另一个原因。

十一、与其他协调组件的对比

选型建议：如果你的系统已经是 Java / Spring Cloud 生态，且需要强一致性的协调服务（分布式锁、Leader 选举），ZooKeeper 是成熟稳定的选择。如果系统是 Kubernetes 生态或 Go 技术栈，etcd 更为合适。如果需求集中在微服务的服务注册与配置管理，Nacos 提供了更丰富的功能（如灰度发布、配置版本管理）。ZooKeeper 的定位更偏向"底层协调原语"，而 Nacos/Consul 更偏向"开箱即用的注册与配置平台"。

总结

ZooKeeper 凭借其 ZAB 协议提供的强一致性、树形数据模型（ZNode）的灵活性、Watcher 事件驱动机制以及 Session 自动清理能力，成为分布式系统中协调服务的经典实现。掌握 ZooKeeper 的核心在于理解其 CP 模型的取舍——它在网络分区时优先保证一致性而牺牲可用性，这决定了它适合作为"协调中枢"而非"海量数据存储"。在实际使用中，务必使用 Curator 框架替代原生 API，关注 Session 超时时间与 JVM GC 停顿的关系，隔离事务日志磁盘以避免 IO 争抢，以及在设计 Watcher 时注意"惊群效应"的链式优化。思考一下：如果你的系统正在从 Dubbo 2.x（ZooKeeper 注册中心）迁移到 Dubbo 3.x（支持 Nacos），在过渡期间如何保证 ZooKeeper 和 Nacos 两套注册中心的数据一致性和服务的平滑发现？