ZooKeeper 是一个分布式协调服务，专为分布式系统设计，能提供**一致性、可靠性和有序性**支持，常被用于服务注册与发现、配置管理、分布式锁、集群选举等场景。其核心设计围绕“分布式一致性”展开，底层依赖 ZAB（ZooKeeper Atomic Broadcast）协议实现数据同步和主从协调，整体架构和工作机制具有鲜明的分布式特征。 从核心架构来看，ZooKeeper 通常以集群形式部署，包含**领导者（Leader）、跟随者（Follower）和观察者（Observer）** 三种角色。Leader 是集群的核心，负责处理所有写请求、发起投票和协调集群一致性；Follower 接收客户端读请求，参与写请求的投票和 Leader 选举；Observer 则仅处理读请求和同步数据，不参与投票，主要用于扩展集群读能力，减轻 Leader 和 Follower 的压力。
这种架构设计既保证了写操作的强一致性（通过 Leader 统一协调），又通过 Follower 和 Observer 提升了读操作的吞吐量，平衡了可用性和性能。 数据模型方面，ZooKeeper 采用类似文件系统的**树形结构（ZNode 树）**，每个节点称为 ZNode。ZNode 不仅可以存储少量数据（默认最大 1MB），还具有独特的**节点类型**和**状态信息**：按持久性可分为持久节点（节点创建后一直存在，除非手动删除）、临时节点（客户端会话结束后自动删除，常用于服务注册）；按顺序性可分为顺序节点（创建时自动添加单调递增的序号，适合分布式锁和队列场景）。此外，每个 ZNode 都包含版本号、时间戳等元数据，用于实现乐观锁机制（如通过版本号判断数据是否被修改）。 最具特色的是 ZooKeeper 的**Watcher 机制**，这是一种轻量级的事件通知机制，允许客户端注册监听特定 ZNode 的变化（如节点创建/删除、数据修改、子节点变化等）。
当被监听的事件发生时，ZooKeeper 会主动向客户端发送通知，客户端无需轮询即可实时感知数据变化。这种机制在服务发现中尤为重要：服务提供者创建临时节点注册服务，服务消费者监听该节点的子节点变化，一旦服务上下线，消费者能立即收到通知并更新服务列表，实现动态感知。 在一致性保障上，ZAB 协议是核心。该协议分为**崩溃恢复**和**消息广播**两个阶段：当 Leader 故障时，集群进入崩溃恢复阶段，通过选举机制从 Follower 中选出新的 Leader，确保数据一致后恢复服务；正常运行时，Leader 接收写请求后，会将数据变更以事务提案的形式广播给所有 Follower，待超过半数 Follower 确认接收后，Leader 才提交事务并通知所有节点更新数据，这种“过半确认”机制保证了数据的最终一致性。 实际应用中，ZooKeeper 的典型场景包括：用临时顺序节点实现分布式锁（通过抢占最小序号节点获取锁）；用持久节点存储集群配置，结合 Watcher 实现配置动态推送；在 Kafka、Hadoop 等分布式系统中作为集群协调器，管理节点状态和选举主节点。不过，ZooKeeper 也存在一些局限，比如写操作性能受 Leader 瓶颈限制、数据存储量较小等，因此在高并发写场景中需结合业务特点合理设计。 总的来说，ZooKeeper 凭借简洁的数据模型、可靠的一致性协议和灵活的通知机制，成为分布式系统中不可或缺的协调工具，为复杂分布式场景提供了稳定的底层支持。
