Zookeeper 的典型应用场景有哪些？

结论先行：ZK 的四个高频场景是注册中心、配置管理、分布式锁、Master 选举；再往外还有命名服务、分布式队列、集群成员管理与元数据存储。共同点是“数据量小、变更不频繁、对一致性敏感”。

一、场景与数据结构对照

二、注册中心的目录约定（Dubbo 风格）

/dubbo
 └── com.demo.UserService
      ├── providers
      │    ├── dubbo://10.0.0.1:20880/...?timeout=3000   （临时节点）
      │    └── dubbo://10.0.0.2:20880/...?timeout=3000
      ├── consumers
      │    └── consumer://10.0.0.9/...                    （临时节点）
      ├── routers
      └── configurators

提供者启动写临时节点，宕机后会话超时由服务端删除；消费者 watch providers 子节点变化，拿到全量 URL 列表并缓存到本地文件。

三、Master 选举示例

// 每个实例都尝试创建临时顺序节点，序号最小者为主
String path = client.create()
        .withMode(CreateMode.EPHEMERAL_SEQUENTIAL)
        .forPath("/election/n_");              // 返回 /election/n_0000000007
String myNode = path.substring(path.lastIndexOf('/') + 1);

List<String> children = client.getChildren().forPath("/election");
Collections.sort(children);                    // 序号补零，字典序即大小序
boolean isLeader = myNode.equals(children.get(0));

if (!isLeader) {
    // 只监听前一个节点，避免惊群
    String prev = children.get(children.indexOf(myNode) - 1);
    client.getData().usingWatcher(watcher).forPath("/election/" + prev);
}

四、选型判断

五、落地前的三个自检

这三条过不了，说明 ZK 不是最优解，而不是 ZK 不好用。

常见追问

• 追问：ZK 做配置中心和 Nacos 的差别？ZK 只有 watch 通知，变更要自己拉全量、自己做版本与灰度；Nacos 提供推送、命名空间、灰度、回滚。
• 追问：为什么不用 ZK 存业务数据？单节点 1MB 限制、写要过半确认、无查询能力，吞吐与功能都不匹配。
• 追问：ZK 队列有什么问题？顺序节点靠父节点 cversion 递增，消费后节点要删除，大量堆积时清理成本高，不适合高吞吐消息场景。

小结

• 注册、配置、锁、选举是四大主场景，都符合“小数据 + 低频变更”。
• 临时节点管存活，顺序节点管排队，watch 管通知。
• ZK 强在协调语义，弱在吞吐与存储。
• 高 QPS 短锁用 Redis，配置管理用专业配置中心。