ZooKeeper 在 Hadoop 生态中的角色

概述

ZooKeeper 是分布式协调服务的"元老"，为 HDFS、HBase、Kafka、YARN 等组件提供一致性保障：谁当主、元数据在哪、节点是否存活，都依赖它。本文先讲清 ZooKeeper 自身的数据模型、Watcher 与 ZAB 协议，再逐个拆解它在 Hadoop 生态里的具体角色。

一、ZooKeeper 是什么

ZooKeeper 是一个高可用的分布式协调系统，提供小规模数据的强一致读写（顺序一致性 + 原子性）。它的定位不是存储业务数据，而是保存"集群状态"。

三个核心设计：

设计	说明
数据量小	所有数据常驻内存，读写极快
强一致	ZAB 协议保证所有节点看到相同数据
会话机制	客户端与服务器通过会话（Session）维持连接与临时节点生命周期

二、数据模型

2.1 ZNode

ZooKeeper 的数据组织成树形节点，称为 ZNode：

/
├── /hbase            (HBase 元信息)
├── /hadoop-ha        (HDFS HA 状态)
│   └── /mycluster    (ActiveStandbyElector 选举节点)
└── /kafka            (Broker 注册、Controller 选举)

节点类型	特点	典型用途
持久节点	手动删除才消失	配置、固定元数据
临时节点	会话结束自动删除	服务在线状态（如 RegionServer 注册）
顺序节点	名称带自增序号	队列、公平锁
临时顺序节点	临时 + 顺序	分布式锁

2.2 Watcher 机制

客户端可对 ZNode 注册 Watcher，节点数据变化或子节点变化时收到一次性通知：

1. 客户端 watch /hbase/master
2. HMaster 宕机，临时节点消失
3. ZooKeeper 向 watch 客户端推送 NodeDeleted 事件
4. 客户端（或备 HMaster）感知后触发主备切换

Watcher 是"一次性"的，收到通知后需重新注册，避免漏通知。

2.3 会话与临时节点生命周期

客户端 connect → 建立 Session → 创建临时节点
客户端断开 → Session 超时（如 30s 内未恢复）→ 临时节点自动删除

生产上 Session 超时需与网络抖动、GC 停顿权衡：太短易误判，太长故障感知慢。

三、ZAB 协议与 Leader 选举

3.1 ZAB 协议

ZooKeeper 的一致性由 ZAB（ZooKeeper Atomic Broadcast）协议保证，核心是原子广播：

阶段	动作
选举阶段	选出 Leader，其他节点为 Follower
发现阶段	同步 Leader 已提交的事务日志
同步阶段	Follower 追平数据，进入就绪
广播阶段	写请求统一由 Leader 分配全局递增的 ZXID 并广播，过半 Follower ACK 后提交

过半机制（Quorum）意味着 3 节点集群容忍 1 台宕机，5 节点容忍 2 台。

3.2 Leader 选举（FastLeaderElection）

选举过程要点：

每个节点投票给自己，广播 (myid, ZXID)。
比较规则：ZXID 大者优先（数据最新），其次 myid 大者优先。
收到过半相同投票即选出 Leader，其余节点进入同步。
老 Leader 恢复后只能当 Follower，防止脑裂（Split Brain）。

3.3 写路径

Client → Follower → 转发 Leader → 分配 ZXID → 广播 → 过半 ACK → 提交 → 响应

读请求由任意节点本地返回（可能读到稍旧数据），ZooKeeper 因此是"顺序一致 + 最终一致的读"，对配置类数据足够。

四、在 Hadoop 生态中的角色

4.1 HDFS HA（核心支撑）

NameNode 主备切换全流程依赖 ZooKeeper：

角色	ZooKeeper 中的机制
Active/Standby 判定	ActiveStandbyElector 在 ZK 创建临时节点，抢到者为主
故障感知	主 NameNode 失联，临时节点消失触发选举
Fencing 辅助	通过 ZK 锁阻止两个 NameNode 同时 Active（防脑裂）

/hadoop-ha/mycluster/ActiveStandbyElectorLock（临时节点）

4.2 HBase

meta 表定位：/hbase/meta-region-server 节点存 meta 表所在 RegionServer。
HMaster 主备选举：多个 HMaster 竞争根节点，胜者服务。
RegionServer 在线注册：每台 RegionServer 建临时节点，宕机即消失，HMaster 感知后转移其 Region。

4.3 Kafka

Controller 选举：首个存活 Broker 在 /controller 建临时节点成为 Controller，负责分区副本分配与 Leader 选举。
Broker 注册：/brokers/ids/0 等节点保存 Broker 信息。
ISR 变化与主题变更：通过 Watch 机制广播给其他 Broker。

4.4 YARN 与 Hive

YARN RM HA：ActiveStandbyElector 机制与 HDFS 相同，ZK 节点记录 RM 状态。
Hive Metastore 高可用：多个 Metastore 通过 ZK 做服务发现。
作业调度协调：早期 Hive/Spark 任务锁、队列状态也可落在 ZK。

4.5 生态角色一览表

组件	ZooKeeper 承担的关键职责
HDFS	NameNode 主备选举、防脑裂锁
HBase	meta 定位、HMaster 选举、RegionServer 存活
Kafka	Controller 选举、Broker 注册、元数据变更广播
YARN	ResourceManager 主备切换
其他	分布式锁、命名服务、配置管理

五、分布式协调应用模式

5.1 分布式锁

加锁：在 /locks 下创建临时顺序节点，序号最小者持锁
等待：Watch 前一个节点，节点删除后重新竞争
释放：删除自己的节点（会话结束也会自动删除，防死锁）

对比 Redis 锁：ZK 锁无过期时间误删问题，但性能较低，适合低频强一致场景（如任务抢占）。

5.2 配置管理

配置以 ZNode 存储，客户端 Watch 该节点，配置变更实时推送，替代重启生效。

5.3 命名服务

把服务地址注册到 ZK 路径，消费方按名字获取地址列表，实现服务发现（早期 Dubbo 的核心机制）。

六、集群部署与注意点

要点	说明
奇数节点	3/5/7，过半可用，2 台没有高可用意义
独立部署	不与 DataNode 混布，避免 IO 抢占
磁盘	数据量小但写频繁，用 SSD 收益明显
监控	关注会话数、watch 数、延迟（`stat` 命令）
Watch 泄漏	频繁注册不注销会撑爆内存，客户端需管理 Watch 生命周期

常见问题速查

问题	原因与处理
客户端连不上	检查防火墙、tickTime 相关超时、磁盘空间
选举频繁	节点间时钟偏移大、网络抖动，检查 NTP 与网络
Watch 不触发	Watcher 一次性，需确认是否重新注册
数据目录膨胀	定期清理快照与事务日志，或用自动清理策略

ZooKeeper 在 Hadoop 生态中的角色 ​

概述 ​

一、ZooKeeper 是什么 ​

二、数据模型 ​

2.1 ZNode ​

2.2 Watcher 机制 ​

2.3 会话与临时节点生命周期 ​

三、ZAB 协议与 Leader 选举 ​

3.1 ZAB 协议 ​

3.2 Leader 选举（FastLeaderElection） ​

3.3 写路径 ​

四、在 Hadoop 生态中的角色 ​

4.1 HDFS HA（核心支撑） ​

4.2 HBase ​

4.3 Kafka ​

4.4 YARN 与 Hive ​

4.5 生态角色一览表 ​

五、分布式协调应用模式 ​

5.1 分布式锁 ​

5.2 配置管理 ​

5.3 命名服务 ​

六、集群部署与注意点 ​

常见问题速查 ​