ZooKeeper 系统学习总结

学习背景：

已在 Dubbo 等系统中间接使用 ZooKeeper

目标：理解 ZooKeeper 的设计边界、核心能力与正确使用方式

一、ZooKeeper 的核心定位

一句话定义：

ZooKeeper 是一个用于维护分布式系统中一致性状态的协调系统。

它不是：

数据库
缓存
消息队列

它解决的是：

多节点对"同一状态"的一致认知
顺序、存在性、唯一性问题

二、ZooKeeper 的数据模型：ZNode

ZooKeeper 中唯一的数据结构是 ZNode，呈树形结构，类似文件系统：

复制代码

/
 ├── dubbo
 ├── config
 └── lock

ZNode 的核心特征

路径（Path）即语义
数据体积很小（KB 级）
自带版本号与元数据（Stat）

ZooKeeper 的价值不在"存什么数据"，而在于节点的存在与变化本身。

三、ZNode 的四种类型（核心能力来源）

类型	特性	典型用途
Persistent	持久存在	配置、规则
Ephemeral	会话断开即删除	服务注册、心跳
Persistent Sequential	持久 + 有序	队列、编号
Ephemeral Sequential	临时 + 有序	分布式锁、选主

四、Watch 机制（ZooKeeper 的灵魂）

Watch 的本质

Watch 是一种一次性、轻量级的变更提醒机制。

关键特性

一次触发即失效，需要重新注册
只保证"发生过变化"，不保证变更次数
不携带完整变更数据，需要客户端主动再拉取

正确类比

Watch 更像文件系统的 inotify，而不是 MQ 或 binlog。

五、ZooKeeper 的典型应用场景

1️⃣ 服务注册与发现

使用 临时节点 表示服务实例
实例宕机 → 节点自动删除
客户端通过 Watch 感知变更

Dubbo、Kafka、HBase 等均采用此模式

2️⃣ 分布式锁（标准实现）

正确做法：临时顺序节点

在锁目录下创建 Ephemeral Sequential 节点
获取所有子节点并排序
序号最小者获得锁
其余节点 Watch 前一个节点

优势：

避免死锁
避免惊群效应

3️⃣ Leader 选举

多个节点创建临时顺序节点
最小序号节点成为 Leader
Leader 宕机 → 自动触发重新选举

本质与分布式锁模型一致

六、ZooKeeper 的一致性模型：ZAB

核心原则

单 Leader 写
写操作需要多数派确认
提供线性一致性

ZAB 的两个阶段

崩溃恢复阶段
- 选出拥有最新数据的 Leader
原子广播阶段
- Leader 生成事务
- 广播给 Follower
- 超过半数 ACK 后提交

七、ZooKeeper 的设计取舍

为什么"慢但稳"？

强一致性带来的写放大
每次写都涉及网络与磁盘同步

明确不适合的场景

高频写
大数据量存储
业务查询
高频配置变更

八、ZooKeeper 在架构中的正确位置

ZooKeeper = 控制面 / 协调层，而不是数据面

与 Dubbo 的关系

ZooKeeper 用作注册中心
不在 RPC 调用链路中
注册中心不可用时，Dubbo 仍可基于本地缓存调用

九、ZooKeeper 的选型结论（可复用）

适合使用 ZooKeeper 的场景

服务注册与下线感知
分布式锁
Leader 选举
元数据管理（低频）

不适合使用 ZooKeeper 的场景

高频配置中心
高并发写系统
业务 KV 存储

十、整体总结

ZooKeeper 是一个为"分布式一致性协调"而生的系统，
其价值在于状态与顺序，而非数据本身。

理解并尊重其设计边界，是正确使用 ZooKeeper 的前提。