Apache ZooKeeper 是一个高性能的分布式协调服务，是许多分布式系统（如 Kafka, Hadoop, Dubbo）背后的“指挥官”。本文将带你从零开始搭建 ZooKeeper 环境，掌握核心命令，并了解其在分布式系统中的典型应用场景。
1. ZooKeeper 核心概念
简单来说，ZooKeeper 提供了一个类似 Linux 文件系统的树形目录结构，每个节点称为 Znode。它主要用于解决分布式应用中经常遇到的数据管理问题，如：统一命名服务、状态同步、集群管理、分布式应用配置项的管理等。
核心特性
- 一致性：集群中各节点的数据保持强一致性（基于 ZAB 协议，ZooKeeper Atomic Broadcast）。
- 高可用：只要集群中半数以上节点存活，服务就能正常工作。
- 实时性：数据变化能实时推送到客户端（Watcher 机制）。
- 有序性：所有事务请求都有全局唯一的事务 ID（ZXID），保证了操作的顺序性。
数据模型 (Znode)
Znode 是 ZooKeeper 存储数据的基本单位，主要有四种类型：
- 持久节点 (Persistent)：创建后一直存在，直到主动删除。
- 场景：存储配置信息、服务地址等长期有效的数据。
- 临时节点 (Ephemeral)：客户端会话断开后，节点自动删除。
- 场景：服务注册发现。服务启动时创建临时节点，宕机或断开连接后节点自动消失，消费者感知到服务下线。
- 持久顺序节点 (Persistent Sequential)：持久节点 + 自动自增后缀。
- 场景：分布式 ID。利用其自动生成的唯一有序后缀。
- 临时顺序节点 (Ephemeral Sequential)：临时节点 + 自动自增后缀。
- 场景：分布式锁。所有客户端创建临时顺序节点，序号最小的获得锁。
2. Docker 快速搭建 ZooKeeper
在本地开发环境中，使用 Docker 搭建 ZooKeeper 是最便捷的方式。
2.1 拉取并启动容器
执行以下命令，启动一个单节点的 ZooKeeper 实例：
docker run -d \
--name zookeeper \
-p 2181:2181 \
-e TZ="Asia/Shanghai" \
-v /d/docker/zookeeper/data:/data \
-v /d/docker/zookeeper/conf:/conf \
zookeeper:3.5.6
参数详解：
-d: 后台静默运行（Daemon 模式）。--name zookeeper: 给容器起个名字，方便后续管理。-p 2181:2181: 端口映射。2181 是 ZK 客户端连接的默认端口。-e TZ="Asia/Shanghai": 设置时区，这对依赖时间的分布式系统非常重要。-v ...:/data: 挂载数据目录，保证容器删除后数据不丢失。-v ...:/conf: 挂载配置目录，方便自定义zoo.cfg。
2.2 进入容器与 CLI
容器启动后，我们可以进入容器内部使用官方提供的命令行工具 zkCli.sh 进行交互。
# 1. 进入容器交互式终端
docker exec -it zookeeper bash
# 2. 启动 ZooKeeper 命令行客户端
./bin/zkCli.sh
连接成功后，你会看到类似 [zk: localhost:2181(CONNECTED) 0] 的提示符，表示已准备好接收命令。
3. ZooKeeper 常用命令详解
在 zkCli 中，我们可以像操作文件系统一样操作 Znode。
3.1 基础 CRUD 操作
| 操作 | 命令格式 | 示例 | 说明 |
|---|---|---|---|
| 查看 | ls [path] |
ls / |
查看根目录下的子节点 |
| 查看详情 | ls -s [path] |
ls -s / |
查看节点及其详细元数据（如事务ID、版本号） |
| 创建 | create [path] [data] |
create /app "config" |
创建持久节点 /app，值为 "config" |
| 读取 | get [path] |
get /app |
获取节点数据及元信息（如 cZxid, mtime） |
| 修改 | set [path] [data] |
set /app "new_config" |
更新节点数据，版本号会增加 |
| 删除 | delete [path] |
delete /app |
删除节点（必须无子节点） |
| 递归删 | deleteall [path] |
deleteall /app |
删除节点及其所有子节点 |
3.2 关键参数详解
创建临时节点（
-e）：create -e /lock "temp_data" # 此时退出 zkCli 再重新登录，get /lock 会提示节点不存在原理：临时节点的生命周期绑定在当前 Session 上。
创建顺序节点（
-s）：create -s /order/seq- "data" # 结果可能是 Created /order/seq-0000000001 create -s /order/seq- "data" # 结果可能是 Created /order/seq-0000000002原理：ZooKeeper 自动维护一个全局递增的计数器，附加在节点名后。
查看节点状态（
stat或ls -s）：
执行stat /可以看到详细信息：cZxid: 创建时的事务 ID。mZxid: 最后修改时的事务 ID。pZxid: 子节点列表最后变更的事务 ID。dataVersion: 数据版本号（乐观锁机制的核心）。ephemeralOwner: 如果是临时节点，这里是 Session ID；否则为 0。
4. 常见应用场景解析
ZooKeeper 强大的协调能力使其在分布式系统中无处不在。
4.1 分布式锁 (Distributed Lock)
原理：
- 客户端在
/locks下创建临时顺序节点（如lock-0001）。 - 判断自己是不是序号最小的节点。
- 是：获得锁。
- 否：监听（Watch）前一个节点（比自己序号小的最大节点）。
- 当前一个节点删除（锁释放）时，触发 Watch 事件，尝试获得锁。
4.2 配置管理 (Configuration Management)
原理：
- 将配置信息存储在 Znode 中（如
/config/db）。 - 所有应用客户端启动时读取该节点，并注册 Watcher。
- 当运维人员修改节点数据（
set /config/db "new_ip"）时，ZK 通知所有客户端。 - 客户端收到通知，重新拉取最新配置，实现配置热更。
4.3 注册中心 (Service Registry)
原理：
- 服务提供者启动时，在
/services/user-service下创建临时节点（如ip:port）。 - 服务消费者启动时，读取该路径下的所有子节点，并注册 Watcher。
- 当提供者宕机，Session 断开，临时节点自动删除。
- ZK 通知消费者，消费者更新本地服务列表，剔除故障节点。
5. 案例：Meituan Leaf 中的 ZooKeeper 应用
美团 Leaf 的 Snowflake 模式 依赖 ZooKeeper 来解决两个核心问题，这里简单介绍其整合思路：
自动管理机器号 (WorkerID)：
Leaf 利用 ZK 的持久顺序节点特性，在启动时自动获取一个全局唯一的 ID 作为 WorkerID，避免了手动配置的繁琐和冲突风险。防止时钟回拨：
Leaf 节点会定期向 ZK 上报自身系统时间。服务启动时，会校验本机时间与 ZK 记录的上次汇报时间。如果发现本机时间“倒流”了，则拒绝启动，从而保证生成的 ID 不重复。
通过这两个机制，Leaf 巧妙地利用 ZooKeeper 保证了分布式 ID 生成的唯一性和安全性。
