ZooKeeper 是一个分布式协调服务，专门解决分布式系统的协作难题，不存储业务数据，只做协调管控。它为分布式系统提供统一的配置管理、服务注册发现、分布式锁、领导选举、集群状态管理等核心能力。分布式系统中节点多、易故障、数据难同步，ZooKeeper 用统一的接口和高可用集群，屏蔽底层复杂的协调逻辑，让各节点能高效协同。它是大数据生态（Kafka、Hadoop、RocketMQ）的基础组件，保证分布式集群稳定运行、数据一致、故障自动处理，是分布式架构的协调中枢。
ZooKeeper 的数据模型是树形层次结构，和文件系统完全一致，核心存储单元叫 ZNode 节点。根节点是/，下面可创建多级子节点，每个节点都能存储少量数据（默认最大 1MB），还自带节点状态、权限、版本号等元数据。节点分不同类型，支持临时、顺序、持久等特性。所有节点在集群中保持一致，客户端通过路径操作节点，比如/config/app。这种模型简单直观，便于分布式系统共享状态、配置，读写操作轻量高效，是 ZooKeeper 实现协调服务的基础。
ZNode 分四大核心类型，满足不同业务场景。持久节点：客户端断开连接后节点依然存在，默认类型，存永久配置。临时节点：客户端会话失效后自动删除，用于服务注册、状态感知。持久顺序节点：持久 + 自动递增后缀，创建时 ZK 自动加序号，保证全局唯一。临时顺序节点：临时 + 自动递增，是实现分布式锁、选举的核心。每个节点都有版本号，用于乐观锁控制；临时节点绑定客户端会话，顺序节点保证全局有序，不同类型组合适配分布式协调的各类需求。
顺序节点是 ZooKeeper 的特殊 ZNode，分为持久顺序和临时顺序两种。创建时，ZK 会自动在节点名后拼接全局唯一的递增数字后缀，比如创建/lock/node，实际节点名为/lock/node0000000001，下一个为 0000000002，序号全局递增不重复。顺序节点无需客户端手动生成唯一标识，天然避免冲突，是实现分布式锁、领导选举的核心基础。它保证了节点的全局有序性，让分布式场景下的公平竞争、排队机制轻松实现，无并发冲突风险。
会话是客户端与 ZK 集群建立的长连接，有唯一 ID 和超时时间，客户端通过会话发送请求、接收监听通知。临时节点完全依赖会话存在：客户端创建临时节点时，节点会绑定当前会话 ID；只要会话保持活跃，临时节点就存在；一旦会话超时、断开（客户端宕机、网络中断），ZK 会自动删除该会话下的所有临时节点。会话心跳机制维持连接，临时节点的生命周期严格跟随会话。这种绑定关系，让 ZK 能实时感知客户端状态，实现服务上下线感知、临时锁自动释放等核心能力。
Watcher 是 ZK 的事件监听通知机制，客户端监听指定 ZNode 节点，节点发生变化时，ZK 主动推送事件通知。工作流程：客户端调用监听接口注册 Watcher；ZK 服务端记录监听关系；节点被创建、删除、数据修改、子节点变化时，服务端触发事件；一次性通知客户端监听结果，通知后 Watcher 立即失效，需重新注册。Watcher 轻量高效，不占用大量资源，实现了分布式系统的实时状态感知，用于配置动态更新、服务发现、集群故障感知等场景，是 ZK 核心特性之一。
ZK 基于临时顺序节点实现公平、可靠的分布式锁，无死锁风险。客户端申请锁时，在锁节点下创建临时顺序节点；获取所有子节点，判断自己是否为序号最小的节点，是则获取锁；不是则监听前一个节点，等待其释放。锁释放分两种：客户端主动删除节点，或会话失效临时节点自动删除。前一个节点删除后，后一个节点收到 Watcher 通知，重新判断获取锁。这种方式实现公平锁，临时节点避免宕机导致锁无法释放，顺序节点保证无竞争冲突，是分布式锁的经典实现方案。
ZK 集群采用临时顺序节点 + 投票机制实现 Leader 选举，集群只有一个 Leader，其余为 Follower。集群启动或 Leader 宕机时，触发选举：所有节点创建临时顺序节点，序号最小的节点成为 Leader，其余节点监听自己前一个序号的节点。Leader 负责写请求处理、事务同步，Follower 处理读请求，转发写请求给 Leader。Leader 宕机后，其临时节点删除，下一个序号节点收到通知，成为新 Leader。选举过程快速、自动，保证集群始终有唯一 Leader，避免脑裂，支撑集群高可用。
Quorum 是 ZK 集群的法定人数机制，即集群正常工作所需的最小可用节点数，计算公式为节点总数/2 +1。比如 3 节点集群，Quorum 是 2；5 节点集群，Quorum 是 3。所有写操作、Leader 选举都必须获得 Quorum 节点的确认，才能判定成功。该机制是 ZK 保证数据一致性、避免脑裂的核心：只有超过半数节点可用，集群才能对外提供服务，防止网络分区时出现多个 Leader、数据不一致。Quorum 机制平衡了集群可用性和一致性，是分布式集群的标准容错设计。
ZK 采用ZAB 协议（ZooKeeper 原子广播协议）保证数据强一致性，所有写请求由 Leader 统一处理。Leader 将写请求封装为事务，广播给所有 Follower；Follower 接收事务后写入日志，返回确认；Leader 收到 Quorum 节点确认，提交事务并通知所有节点落地数据。集群保证全局顺序一致性，所有节点按相同顺序执行事务；最终一致性，所有节点最终数据完全一致；读请求在任意节点执行，满足最终一致。ZAB 协议让 ZK 在分布式环境下，实现了高可用 + 强数据一致。
顺序一致性是 ZK 的核心特性，指所有客户端看到的事务执行顺序完全一致。基于 ZAB 协议实现：所有写请求必须由 Leader 统一接收，按全局唯一的事务 ID（ZXID）排序；Leader 将事务按 ZXID 顺序广播给所有 Follower 节点；所有节点严格按照 ZXID 的顺序执行事务，不允许乱序。无论客户端连接哪个节点，读取到的数据变更顺序都和 Leader 执行顺序一致。顺序一致性避免了分布式场景下的事务乱序、数据冲突，保证了分布式系统的状态统一，是协调服务的关键保障。
ZK 集群的数据同步基于ZAB 协议，分启动同步和运行同步。启动 / 故障恢复时，Follower 节点对比自身 ZXID 和 Leader，落后则从 Leader 拉取全部事务日志，补齐数据，完成同步后加入集群。运行时，Leader 处理写请求，将事务广播给所有 Follower，Follower 写入本地日志并确认，Leader 提交后统一落地。同步分为全量同步（数据差异大）和增量同步（仅同步缺失事务），保证所有节点数据最终一致。同步过程自动完成，无需人工干预，支撑集群高可用。
CAP 理论指一致性（C）、可用性（A）、分区容错性（P），分布式系统只能三选二。ZK选择 CP（一致性 + 分区容错性），牺牲部分可用性。网络分区发生时，ZK 必须保证 Quorum 节点可用才能提供服务，不足半数则集群不可用，优先保证数据强一致，不允许出现脏数据。它不追求完全的高可用，而是保证分布式协调的核心：数据绝对一致、无脑裂、无冲突。这也是 ZK 适合做协调服务，不适合做高可用存储的原因，符合其定位。
事务日志是 ZK 保证数据不丢失、可恢复的核心机制。所有写操作都会被封装为带唯一 ZXID 的事务，写入磁盘事务日志文件，日志顺序追加、持久化落盘后，才返回客户端成功。事务日志是顺序写，性能极高，记录了所有数据变更操作。当节点重启、故障恢复时，ZK 会读取事务日志，重放所有未落地的事务，恢复数据到最新状态。配合快照机制，事务日志能快速恢复节点数据，保证集群数据持久化、不丢失，是 ZK 可靠性的基础。
ZK 通过快照 + 事务日志实现数据持久化与快速恢复。事务日志：顺序记录所有写事务，实时落盘，保证变更不丢失。快照：定期将内存中的全量数据导出为快照文件，存储当前所有节点的状态，减少日志重放量。数据恢复时，先加载最新快照文件，再重放快照之后的事务日志，快速恢复到最新状态。快照是全量备份，日志是增量记录，两者结合，既保证了数据持久化，又提升了恢复效率，避免日志无限膨胀，是 ZK 存储的核心设计。
ACL 是 ZK 的权限控制机制，为 ZNode 节点设置细粒度访问权限，保证数据安全。ACL 由三部分组成：权限模式（IP、Digest、World）、授权对象（IP 地址、用户名密码）、权限（读、写、创建、删除、管理）。创建节点时可绑定 ACL 规则，未授权客户端无法操作节点。默认权限为 World（任何人可访问），生产中常用 Digest 模式（账号密码认证）和 IP 白名单。ACL 实现了节点级别的权限隔离，防止未授权访问、误操作，保障分布式协调数据的安全性。
Follower 和 Observer 都是 ZK 集群的从节点，核心区别在是否参与选举和投票。Follower：处理读请求，转发写请求给 Leader；参与 Leader 选举、事务投票，计入 Quorum 数量。Observer：仅处理读请求、转发写请求；不参与选举、不投票，不计入 Quorum。Observer 的作用是扩展集群读能力，不增加选举压力，适合大规模集群、跨地域部署。Follower 保证集群一致性和高可用，Observer 提升读吞吐，两者搭配，兼顾集群稳定性和性能。
脑裂是网络分区后，集群出现多个 Leader 的问题，ZK 通过Quorum 法定人数机制彻底解决。网络分区时，集群被分割为多个子网，只有拥有 ** 超过半数节点（Quorum）** 的子网能选举 Leader、处理请求；不足半数的子网无法选举 Leader，暂停服务。全局只会有一个子网满足 Quorum，产生唯一 Leader，避免多 Leader 脑裂。同时，ZAB 协议保证事务仅在 Quorum 确认后提交，分区恢复后，数据自动同步对齐。该机制从根源杜绝脑裂，保证集群唯一、数据一致。
ZK 是分布式协调神器，核心场景：1. 配置中心：统一管理分布式配置，动态推送更新；2. 服务注册发现：服务上下线注册临时节点，客户端监听感知；3. 分布式锁：基于临时顺序节点实现公平锁；4. 领导选举：集群选主，保证唯一 Leader；5. 集群状态管理：感知节点故障，自动故障转移；6. 分布式队列：顺序节点实现消息排队；7. 分布式 barriers：同步分布式任务执行。广泛应用于 Kafka、Hadoop、RocketMQ 等中间件，是分布式架构的基础组件。
ZK 作为分布式事务协调器，实现最终一致性事务（2PC/3PC）。事务发起者作为 Coordinator，通过 ZK 创建事务节点，记录事务状态；各参与者监听节点，执行本地事务后上报状态到 ZK。Coordinator 收集所有参与者状态，全部成功则提交事务，任意失败则回滚。ZK 的节点状态、Watcher 机制保证事务状态全局可见，临时节点感知参与者宕机，自动触发回滚。ZK 不直接处理业务事务，而是提供统一的协调、状态管理，解决分布式事务的提交、回滚、故障恢复问题。
服务发现基于临时节点 +Watcher实现，保证准确可靠。服务启动时，在 ZK 注册临时节点，存储服务地址、端口信息；服务宕机、会话失效，临时节点自动删除。客户端订阅服务节点，通过 Watcher 监听节点的创建、删除事件，实时感知服务上下线。ZK 集群保证节点数据一致，所有客户端看到的服务列表完全相同；Quorum 机制保证集群高可用，部分节点故障不影响服务注册。临时节点自动清理、Watcher 实时通知、集群数据一致，三重保障服务发现精准可靠。
ZK 采用NIO 非阻塞 IO+ 会话管理支撑海量客户端连接。底层用 NIO 模型，单线程处理多路连接，无需为每个客户端创建独立线程，资源占用极低。客户端会话通过心跳维持，ZK 定时检测会话超时，自动清理失效会话和临时节点。请求处理：读请求在本地节点直接响应，写请求转发给 Leader 统一处理，批量提交提升效率。集群横向扩展节点，增加读吞吐；Observer 节点扩展连接数，不影响选举。轻量的设计让 ZK 能轻松支撑数万客户端并发连接、请求。
ZK 运维核心是高可用 + 监控 + 参数调优。最佳实践：集群部署 3/5/7 奇数节点，保证 Quorum；开启四字命令监控，监控节点状态、会话数、延迟；用 Prometheus+Grafana 做可视化监控，告警会话超时、节点宕机、事务堆积；定期清理快照和日志，配置自动清理策略；JVM 参数调优，设置合适堆内存，避免 GC 卡顿；生产禁用单机模式，跨机架部署节点防单点故障；定期备份事务日志和快照，防止数据丢失。规范运维能保证 ZK 集群 7×24 小时稳定运行。
ZK 基于 JVM 运行，内存管理和 GC 针对性优化。内存：数据存储在内存，节点数据量小（1MB/ 节点），内存占用可控；设置堆内存Xmx/Xms，避免内存溢出。GC 策略：默认用 CMS/G1 垃圾回收器，针对 ZK 短生命周期对象多的特点，降低 STW 停顿；避免频繁 GC，调整新生代大小，减少回收频率。ZK 自身会自动清理失效会话、临时节点，释放内存；快照和日志自动清理，防止磁盘溢出。轻量的数据结构 + 优化的 JVM 参数，让 ZK 内存稳定、GC 无卡顿，保证服务低延迟。
