一文搞懂 ZooKeeper 原理

ZooKeeper 是分布式系统的协调基石，核心是提供强一致、高可用的命名服务、配置管理、分布式锁与集群协调，底层靠 ZAB 协议、树形数据模型、Leader 选举与 Watch 机制实现。

一、核心定位与设计目标

• 定位：分布式协调服务，解决分布式场景下的一致性、配置同步、服务发现、锁与集群管理问题。
• 设计目标：强一致、高可用、顺序性、简单数据模型、高性能读、故障自动恢复。

二、数据模型：树形 ZNode 空间

• 结构：类似文件系统的树形目录，根为 /，每个节点称 ZNode，可存少量数据（默认 1MB）。
• 节点类型：
  • 持久节点：创建后永久存在，需显式删除。
  • 临时节点：会话失效时自动删除，不可设子节点。
  • 顺序节点：创建时自动追加递增序号，用于互斥与队列。
• 元数据：每个 ZNode 存版本号、数据长度、创建/修改时间、ACL 权限，支持多版本控制。

三、集群架构与角色分工

• 集群模式（Ensemble）：通常 3/5/7 台服务器，奇数台保证半数以上容错。
• 角色分工：
  • Leader：唯一写入口，分配全局 ZXID，广播事务提案，协调提交。
  • Follower：参与选举，响应提案，本地落盘，处理读请求，转发写请求。
  • Observer：无投票权，不参与选举/提案，仅同步数据，提升读吞吐。

四、核心协议：ZAB（ZooKeeper Atomic Broadcast）

ZAB 是专为 ZooKeeper 设计的崩溃可恢复原子广播协议，保证数据一致性，含两种模式：

1. 恢复模式：Leader 失效时，集群选举新 Leader，同步数据保证一致。
2. 广播模式：正常服务时，写请求经 Leader 提案、半数以上 Follower 落盘后提交，读请求任意节点处理。

关键机制

• ZXID：全局唯一 64 位事务 ID，高 32 位为纪元（Leader 周期），低 32 位为递增序号，保证事务顺序。
• 过半提交：写操作需半数以上节点确认才生效，兼顾一致性与可用性。

五、Leader 选举流程

1. 触发条件：集群启动、Leader 失联（心跳超时）。
2. 选举规则：优先看 ZXID（数据新者优先），再看 Server ID（大者优先）。
3. 过程：节点互相投票，收集选票，得票超半数者当选 Leader，新 Leader 同步数据后服务恢复。

六、Watch 机制：事件驱动通知

• 原理：客户端在 ZNode 注册 Watch，节点变化（创建/删除/数据修改/子节点变化）时，服务端一次性推送通知，需重新注册持续监听。
• 适用场景：配置变更通知、服务上下线感知、分布式锁状态监听。
• 特性：一次性、轻量、异步通知，避免轮询，降低网络开销。

七、会话管理与持久化

• 会话（Session）：客户端与服务端建立 TCP 连接，含超时时间，心跳保活；超时则会话失效，临时节点删除。
• 持久化：
  • 事务日志：记录所有写操作，用于故障恢复。
  • 数据快照：定期全量快照，加速重启恢复，减少日志回放时间。
• 恢复流程：加载最新快照 → 回放快照后未提交的日志 → 完成数据恢复。

八、核心特性与保证

• 顺序一致性：按请求发送顺序执行，全局一致。
• 原子性：写操作要么全成功，要么全失败。
• 单一视图：客户端连任意节点，数据视图一致。
• 可靠性：写操作成功后永久保存，直至被覆盖。
• 及时性：客户端在一定时间内看到最新数据。

九、典型应用场景

• 配置中心：集中管理配置，变更实时推送。
• 服务注册与发现：节点上下线自动感知，动态调整。
• 分布式锁：利用临时节点与顺序节点实现互斥。
• 集群 Leader 选举：如 HBase Master、Kafka Broker 选举。
• 分布式队列：顺序节点实现先进先出。

十、总结

ZooKeeper 以树形 ZNode 为数据载体，ZAB 协议为一致性核心，Leader 选举为高可用保障，Watch 机制为事件驱动，提供一套简单可靠的分布式协调原语，是分布式系统中不可或缺的基础设施。

需要我把以上内容整理成一页式思维导图大纲，或补充常见面试题与实战配置要点吗？