ZooKeeper 数据模型

某团队使用 ZooKeeper 实现服务注册与发现时，发现注册中心的节点数量随服务实例数线性增长，当实例数达到 10000+ 时，ZooKeeper 的性能急剧下降。

排查后发现：每个服务实例都创建了一个临时节点，而 ZooKeeper 的 Watch 机制每次都要通知所有订阅的客户端，当节点数量大时，通知风暴成为瓶颈。

这是 ZooKeeper 在大规模服务发现场景下的典型性能问题。

【架构权衡】 ZooKeeper 的数据模型适合"小规模、高一致性"场景，不适合"大规模、高并发"场景。在选择 ZooKeeper 之前，需要评估服务实例数量和调用量。

一、核心问题 🔴

1.1 ZooKeeper 节点类型

ZooKeeper 节点类型：

1. 持久节点（Persistent）
   └─ 创建后一直存在，直到显式删除

2. 临时节点（Ephemeral）
   └─ 客户端会话断开后自动删除
   └─ 适合：服务注册（实例下线自动清理）

3. 持久顺序节点（Persistent_Sequential）
   └─ 持久 + 序号
   └─ 适合：分布式锁

4. 临时顺序节点（Ephemeral_Sequential）
   └─ 临时 + 序号
   └─ 适合：分布式锁

ZNode 数据：
├─ 数据大小限制：1MB
├─ 版本号：每次修改递增
└─ ACL：权限控制

1.2 Watch 机制

Watch 机制原理：

1. 客户端注册 Watch
   └─ getData("/path", watcher)
   └─ setData("/path", data, version)

2. 服务端触发 Watch
   └─ 数据变更
   └─ 节点删除
   └─ 子节点变更

3. 客户端收到通知
   └─ One-time trigger（一次性）
   └─ 重新注册 Watch

特点：
├─ One-time trigger：收到通知后需要重新注册
├─ 异步推送：服务端主动推送通知给客户端
└─ 本地顺序：保证客户端看到的变更顺序

二、Redis / etcd / ZooKeeper 对比

对比	Redis	etcd	ZooKeeper
数据结构	KV	KV + MVCC	树形
一致性	最终一致	Raft 强一致	ZAB 强一致
CAP	AP	CP	CP
Watch	Pub/Sub	支持	支持
性能	高	中	中
适用场景	缓存、锁	配置中心	服务发现、分布式锁

三、落地 Checklist

容量评估：评估节点数量和 Watch 数量
集群规模：生产环境至少 3 节点
数据限制：单节点数据不超过 1MB
监控部署：监控节点数量、Watch 数量

#ZooKeeper 数据模型

#一、核心问题 🔴

#1.1 ZooKeeper 节点类型

#1.2 Watch 机制