7.1 Kafka 与 Hadoop 里的 ZooKeeper：重量级客户的用法

7.1 Kafka 与 Hadoop 里的 ZooKeeper：重量级客户的用法

本节摘要：Kafka 用 ZooKeeper 做控制器选举与成员登记，并最终用 KRaft 自研协议完成替代；Hadoop 系组件用它做主备切换与调度协调。拆解这些重量级用法，能提炼出"只存元数据、按组件分目录、写入极克制"三条工程纪律。

走访最大的客户：Kafka

Kafka 与 ZooKeeper 的关系是一段完整的"合作到分手"史，值得完整走一遍，因为每一步都有教育意义。

蜜月期：Kafka 集群把三类小数据托付给 ZooKeeper——Broker 成员登记（每个 Broker 上线注册临时节点）、控制器选举（集群里选一个 Broker 当 Controller，负责分区主副本的分配与故障转移）、以及早期版本的消费位移存储。注意分工的干净程度：消息本体从未进过 ZooKeeper，它只记"谁是谁、谁管事"这类小账。

摩擦期：规模上量后，问题来了。几万分区重平衡时，Controller 要经 ZooKeeper 写大量状态，写路径（4.1 节的表决加 fsync）成为瓶颈；运维还要同时养两套分布式系统（Kafka 加 ZK 各一套监控、容量、升级流程）。更大的痛点在扩缩容的弹性——ZooKeeper 的多数派模型对"动态加减节点"并不友好。

分手期：Kafka 自研 KRaft 协议（Kafka Raft），把元数据的共识收回集群内部：不再外挂协调服务，Broker 与 Controller 融为一体，元数据作为内部日志自管理。新版 Kafka 已完成 ZooKeeper 的全量替代。分手的原因没有一条是"ZooKeeper 不好"——全部是"规模超出了外挂协调层的设计甜区"。这个结论对使用者极具价值：协调服务是粘合剂，不是承重墙，业务规模大到一定程度就该把元数据治理内化。

图：Kafka 与 ZooKeeper 的分工与分离路线

走访老牌客户：Hadoop 系

Hadoop 生态是 ZooKeeper 的发源地之一，HDFS 与 YARN 的用法至今仍是标准教材。HDFS NameNode 主备切换：两台 NameNode 一主一备，谁为主由 ZooKeeper 的临时节点裁定（与 5.3 判例同构），备机监听主机节点，主挂即抢锁接任——注意到没有，这正是第五章判例三的"工业加强版"，外加 fencing（隔离机制）防止旧主复活双写：新主接管前先确保旧主无法再写共享存储，这一步是业务选主判例里没有、而生产级实现必须有的。

YARN 资源调度：ResourceManager 的主备同样靠它裁定；任务提交时作业状态经它协调。HBase 的用法更深：RegionServer 成员登记、Master 选举、Region 分配的协调全走 ZooKeeper，meta 表的定位入口也由它指路——一个组件把 5.3 与 5.4 两个判例同时用满。

# 在 Hadoop 集群的 ZK 上走访一圈：各组件各占一树
[zk] ls /
[hbase, hadoop-ha, yarn-leader-election, zookeeper]
[zk] ls /hadoop-ha/mycluster
[ActiveBreadCrumb, ActiveStandbyElectorLock]
# ^ HDFS 主备选举的两个节点：锁节点裁定谁主，面包屑节点记录最近的主

# 成员登记的现场（HBase）：
[zk] ls /hbase/rs
[datanode1,16020,1724000000000, datanode2,16020,1724000000000]
# 临时节点，RegionServer 掉线自动摘除 —— 5.4 节注册判例的原样重演
​

两个细节值得驻足。ActiveStandbyElectorLock 的命名直白地告诉你：主备切换在 Hadoop 的实现里就是一把分布式锁，5.2 节的全部原理直接适用。面包屑节点则是 fencing 的落点——新主在锁上留名，旧主重启时读到面包屑知道"我已经被替代"，自觉退位。小设计，大用途：把"防复活"做进了数据本身。

提炼：你的系统该抄谁的作业

走访完两个客户，作业清单其实只有三条纪律（图中所列）加一个加分项——学 Hadoop 的 fencing：任何"临时节点裁定身份"的场合，都要回答"旧持有者复活后凭什么知道自己已失效"。答案可以是面包屑式的数据自证，也可以是 6.1 节的行动前重验。把这些纪律内化，你的系统在用法层面就不输大厂。

要点回顾

• Kafka 分工史即教科书：只托付成员登记、控制器选举这类小账，消息数据从不进协调层。
• KRaft 分手的动因：规模超出外挂协调甜区、双系统运维成本、弹性不足——不是 ZooKeeper 不行。
• Hadoop 用法与第五章判例同构：主备切换即分布式锁加 fencing，成员登记即临时节点注册。
• 三条纪律一条加分：只存元数据、分目录、克制写，再加"身份自证的 fencing"。

常见疑问

问：存量 Kafka 还在用 ZooKeeper，需要急着迁移吗？ 不需要。存量集群按现有架构运维即可，迁移是版本升级路线的自然一站；倒是新建集群应直接选 KRaft 模式，避免再养一套外挂协调。

下一站转到微服务语境：Dubbo 如何把注册中心这份差事交给 ZooKeeper。

迁移视角：KRaft 教科书式的替代路径

Kafka 的替代工程给所有"想换掉协调层"的团队留了一份路线图：先在新版本提供双模式（外挂与 KRaft 并存，按配置切换）；再让新集群默认新模式、存量集群按节奏迁移；最后移除旧模式。迁移期两套元数据并行、以 KRaft 为准。启示有两点——替代是渐进的开关切换，不是重写；迁移期可回退（模式可切回）是迁移能推进的政治前提。你的系统若要替换 ZooKeeper，把这份路线图先画出来再动手。

延伸追问

问：KRaft 之后，大数据生态里 ZooKeeper 还剩哪些阵地？ HDFS 与 YARN 的主备协调、HBase、以及大量自研老系统的选主与注册。这些阵地稳定且不活跃迁移——掌握 ZooKeeper 的运维技能在可预见的年限内仍是一张有效的牌。

延伸追问补充

问：借鉴大厂用法时，最先抄哪一条？ 分目录隔离。它成本最低（改命名规范即可）、收益立竿见影（权限、监控、清理都可按树操作）、且是其余一切治理的前提——没有目录边界，限流与 ACL 都无从下手。4.5 节的 namespace 与本节的纪律二合起来用，一天就能落地。