ZooKeeper 介绍

1. 什么是 ZooKeeper

ZooKeeper 是一个分布式协调服务，设计初衷是为分布式软件提供一致性服务。本质上可以看作文件系统 + 通知机制。

ZooKeeper 提供类似 Linux 的树形 ZNode 结构，每个节点既可存数据也可有子节点，并支持对每个节点的监控（Watcher）与通知。

2. ZooKeeper 的工作机制

ZooKeeper 采用主从架构。从设计模式角度，它是基于观察者模式的分布式服务管理框架：负责存储和管理共享数据，接受观察者注册，数据状态变化时通知所有已注册的观察者。

3. ZooKeeper 的角色

4. 事务处理四个阶段

1. 选举阶段：选出 Leader
2. 发现阶段：Follower 与 Leader 建立连接
3. 同步阶段：新 Follower 与 Leader 数据同步
4. 广播阶段：Leader 广播事务提案，过半 Follower ACK 后提交

Leader 选举机制

ZooKeeper 配置文件中没有指定 Master/Slave，Leader 通过内部选举临时产生。

选举规则

每个 Server 投票包含 (myid, zxid)：

• zxid 大者优先：表示数据更新
• zxid 相同时 myid 大者优先

选举流程（5 节点集群示例）

假设 5 个节点编号 Server1 ~ Server5，初始均为 shutdown。

Server 1 启动

Server 1 提议自己为 Leader 并投票 (1, 0)，其他节点未启动，收不到反馈，Server 1 进入 Looking 状态。

Server 2 启动

Server 2 投票 (2, 0)，与 Server 1 交换选票。Server 2 的 myid 更大，Server 2 胜出，但票数 2 < 3（未过半），两者仍为 Looking。

Server 3 启动

Server 3 投票 (3, 0)，与 Server 1、2 交换选票。Server 3 的 myid 最大且票数 3 ≥ 过半，Server 3 成为 Leader，Server 1、2 成为 Follower。

Server 4 启动

Server 4 投票后发现 Server 3 已是 Leader，自动成为 Follower。

Server 5 启动

与 Server 4 相同，发现已有 Leader，成为 Follower。

运行时 Leader 宕机

Leader 宕机后所有节点重新进入 Looking，重新按 (zxid, myid) 规则选举。zxid 最大的 Follower 更可能成为新 Leader，以减少数据同步量。

典型应用场景

• 分布式锁：临时顺序节点 + Watch 前驱节点
• 服务注册与发现：临时节点注册服务地址，客户端 Watch 变化
• 配置中心：配置写入 ZNode，客户端 Watch 热更新
• Leader 选举：同一任务只有一个 Leader 节点工作

使用注意

1. 集群节点数建议奇数（3、5、7），保证过半机制
2. Watcher 是一次性的，触发后需重新注册
3. 避免在 ZNode 存储大量数据，单节点建议 < 1MB
4. 会话超时（Session Timeout）过短易触发频繁 Rebalance