ZooKeeper 通俗指南：分布式系统的“老干部分管”

Apache ZooKeeper 是一个分布式协调服务。
它在 Hadoop 生态系统中地位极高，虽然现在云原生时代 etcd 很火，但在大数据界（Kafka, Hadoop, HBase, Spark），ZooKeeper (ZK) 依然是必须得拜的码头。

1. 它是做什么的？(红绿灯与公证处的比喻)

在分布式系统里，几十台机器乱哄哄地跑，很容易出问题：

• “谁是 Master？”
• “机器 A 只要活着，我就不干活；它死了我再顶上。”
• “大家都准备好了吗？准备好了再一起开始。”

ZK 就是那个站在十字路口的红绿灯，或者是公证处。
它不处理复杂的业务数据（不像 MySQL 存订单，不像 Redis 存缓存），它只存极少量的、关于系统状态的核心数据。

核心职责：
确保大家看到的“视图”是一致的。如果 ZK 说“即使是只猪当了 Leader”，那么所有节点都必须承认它是 Leader。

2. 核心数据结构：一棵小树 (ZNode)

ZK 的数据模型非常简单，长得跟 Linux 文件系统一模一样，是一棵树。
树上的每一个节点叫 ZNode。

• / (根)
  • /apps
  • /config
    • /db-url: “jdbc:mysql://…”
  • /consumers

ZNode 的特殊技能：

1. 持久节点：像普通文件，建了就在那，除非你删它。
2. 临时节点 (Ephemeral)：这是 ZK 的杀手锏。
   • 客户端连着 ZK 时，在这个节点就在。
   • 客户端一旦断开连接（比如机器挂了，心跳断了），这个节点自动消失。
   • 用途：机器上线/下线检测。机器上线创建一个临时节点，机器挂了节点自动没，监控程序一看节点没了就知道出事了。
3. 顺序节点：
   • 你创建 /task-，它自动帮你变成 /task-0000001。
   • 用途：分布式锁（谁的号最小，谁就抢到了锁）。

3. 典型应用场景

A. 选主 (Leader Election)

1. 比如 HBase 集群启动，大家都想当 Master。
2. 大家都去 ZK 建同一个临时节点 /hbase/master。
3. ZK 保证只有一个能创建成功。成功的那个就是 Master。
4. 输了的人就盯着 (Watch) 这个节点。
5. 如果 Master 挂了（临时节点消失），ZK 通知其他人，其他人再发起新一轮抢注。

B. 配置管理

1. 所有服务启动时都去读 /config/db-pwd。
2. 管理员修改了密码。
3. 依靠 ZK 的 Watch 机制，所有服务立马收到通知，热加载新配置（不需要重启）。

C. 分布式锁

1. 想操作共享资源，先去 ZK 创建个临时顺序节点。
2. 看自己是不是序号最小的。
3. 是 -> 获得锁。
4. 不是 -> 监听比自己小的那个人，等他干完。

4. ZK vs Etcd

总结

• ZK 是用来管事儿的，不是用来存大量数据的。
• 它的临时节点机制是很多分布式系统高可用的基石。
• 如果你在搞大数据（Hadoop 全家桶），ZK 是你的必修课。