ZooKeeper 与协调原语

• Curator 分布式锁的锁节点模型（临时顺序节点）
• 获取锁的竞态与 Watch 监听机制
• 可重入锁的计数与线程绑定

InterProcessMutex 基于 ZooKeeper 的临时顺序节点实现。加锁时，客户端在指定锁路径下创建临时顺序节点（EPHEMERAL_SEQUENTIAL），然后获取该路径下所有子节点列表并排序，判断自己创建的节点是否为最小节点。如果是最小节点，则成功获取锁；否则监听前一个比自己小的节点（而不是监听所有节点，避免"惊群效应"），当监听到前一个节点被删除后重新判断。释放锁时删除自己的临时节点，其 Watch 会触发后一个节点获得锁。InterProcessMutex 支持可重入，内部维护一个 ConcurrentMap 记录当前线程的锁计数，同一线程重复加锁时计数递增，只有计数归零才真正删除节点。

采用"监听前一个节点"而非"监听所有节点"是避免惊群效应的关键，只有相邻的节点才会被唤醒，保证了锁获取的公平性（FIFO）。临时节点+Watch 的组合保证了即使客户端崩溃，锁也会在会话过期时自动释放，避免死锁。可重入性由线程本地计数实现，与 Java 的 ReentrantLock 语义一致。

• ZAB 协议的两阶段提交与原子广播
• Znode 的持久/临时/顺序节点类型
• Znode 的 stat 字段（version/cversion/aversion）

ZAB 协议是 ZooKeeper 保证数据一致性的核心，它将写入操作通过 Leader 节点进行，采用"两阶段提交"式的原子广播：所有写请求由 Leader 接收并分配 zxid（单调递增的事务ID），Leader 将事务 Proposal 广播给所有 Follower，Follower 收到后写入本地事务日志并返回 ACK，Leader 收到半数以上 ACK 后提交事务并通知所有节点。Znode 数据模型是树形层次结构，每个节点可存数据（默认 1MB 限制）并可有子节点。节点类型包括持久节点（PERSISTENT）、临时节点（EPHEMERAL，会话结束自动删除）、持久顺序节点、临时顺序节点。每个 Znode 有 stat 元数据，包含 dataVersion（数据版本）、cversion（子节点版本）、aversion（ACL 版本）、ctime、mtime、czxid、mzxid 等字段。

ZAB 的"两阶段提交+半数 ACK"保证了在任何时刻写入都能被多数节点确认，从而在 Leader 崩溃后有足够的数据完成恢复。版本号字段是实现乐观锁的基础，Znode 数据模型采用树形结构便于按路径组织配置和协调元数据。顺序节点编号由父节点维护，保证全局唯一单调递增。

• 临时节点的会话绑定与自动清理
• 顺序节点的单调递增编号
• 分布式锁与选主的实现对比

临时节点的生命周期与会话绑定，会话结束（超时或客户端主动断开）时节点自动删除，因此非常适合实现"客户端崩溃自动释放"的语义。顺序节点由父节点维护一个单调递增的计数器，保证创建的节点编号严格递增且不重复。在分布式锁中，客户端创建临时顺序节点，取编号最小的节点（持锁者）成功获得锁，其他客户端监听前一个节点。在 Leader 选举中，所有候选者创建临时顺序节点，编号最小的节点成为 Leader，其余节点监听前一个节点，当前 Leader 会话失效后其临时节点被删除，触发下一个节点成为新 Leader。临时节点保证了崩溃后自动让位，顺序节点保证了公平的选举顺序。

"临时"解决了故障自动释放问题，"顺序"解决了公平排队的先来先服务问题，两者结合是分布式锁和选主的标准做法。相比 Redis 分布式锁，ZooKeeper 方案的强一致性（ZAB）保证了锁的可靠性，但性能较慢且依赖会话心跳。

• 四种认证方案（world/auth/digest/ip）
• 五种权限（READ/WRITE/CREATE/DELETE/ADMIN）
• 权限的叠加与父子关系

ZK 的 ACL 由多个 schema:perm 对组成，schema 是认证方案，perm 是权限位。四种认证方案：world（对所有用户开放，无认证）、auth（当前会话认证的用户）、digest（用户名:密码的 SHA1 摘要）、ip（按客户端 IP 匹配）。五种权限：READ（读数据及子节点）、WRITE（写数据）、CREATE（创建子节点）、DELETE（删除子节点）、ADMIN（设置 ACL）。注意 CREATE 和 DELETE 是分开的权限，且针对的是子节点操作。生产环境建议：默认禁用 world:anyone:cdrwa，使用 digest 认证为不同应用配置独立账号密码，对关键节点（如锁节点、配置节点）设置最小权限，开启认证（authProvider）并配置 ACL 指定到具体客户端。

ZK 的 ACL 权限是"非递归"的，即对父节点设置 ACL 不会自动应用到子节点，子节点需单独设置。权限模型相对简单，适合信任边界内的服务协调场景，生产环境应通过 digest/ip 认证限制访问范围，避免任意客户端读写核心配置。

• 乐观锁基于 dataVersion 的 CAS 操作
• 悲观锁基于临时节点的互斥
• 适用场景与性能

乐观锁利用 Znode 的 dataVersion 字段实现 CAS（Compare and Swap）：客户端先读取节点数据及其 dataVersion，更新时通过 setData 接口携带已读到的版本号，如果版本号与当前版本一致则更新成功，否则抛出 BadVersionException 表示数据已被其他客户端修改，此时需要重新读取并重试。悲观锁则通过创建临时节点（或临时顺序节点）实现互斥，只有成功创建节点的客户端才能获得锁，其他客户端阻塞等待，直到持有者释放或会话过期。乐观锁适合读多写少、冲突概率低的场景，通过重试提高并发；悲观锁适合写多、冲突概率高、需要严格串行化的场景。

ZK 的乐观锁本质是"版本号校验"，底层通过事务的原子性保证版本判断与写入的原子性；悲观锁本质是"临时节点互斥"加"Watch 等待"。两者的取舍核心是并发度与一致性的平衡，乐观锁冲突时重试代价较低，悲观锁阻塞等待更简单直接。

• 一致性协议（ZAB vs Raft）
• 数据模型（Znode 树 vs KV）
• 接口（Java API vs gRPC）

ZooKeeper 使用 ZAB 协议，etcd 使用 Raft 协议，两者都是 CP 系统（强一致）。数据模型上，ZK 是树形 Znode 结构，适合层次化配置；etcd 是扁平 KV 结构，支持前缀查询和 Watch 范围监听。接口上，ZK 使用自定义的 Java 客户端 API 和自研协议，etcd 使用标准 gRPC + protobuf。性能上，ZooKeeper 的写性能受限于 Leader 刷盘，etcd 的多次读取（线性读）和 Watch 性能更好。生态上，ZK 是 Kafka、HBase、Hadoop 的经典依赖，etcd 是 Kubernetes 的核心存储。etcd 的 MVCC、lease、Watch 流式监听设计更现代，运维更简单（无需 ZK 的 4lw 命令），因此在新项目中 etcd 更受青睐。

两者本质都是"CP 协调器"，区别在于工程实现和生态。ZK 更成熟但 API 陈旧、Watch 一次性；etcd 基于 gRPC 的 Watch 流式推送、MVCC 多版本、lease 机制更贴合云原生场景。选择时主要看周边生态（Kafka 需要 ZK）与团队熟悉度。

• Quorum 的最小值要求
• 半数以上原则的容错能力
• 脑裂的成因与防护

Quorum 是 ZooKeeper 集群中完成事务提交所需的最小确认节点数，通常为半数以上（N/2+1）。只有获得 Quorum 确认的事务才能提交，因此任何时刻最多只有一个 Quorum 存活，这就防止了脑裂：如果在网络分区后集群分裂成两部分，只有包含多数节点的那部分能继续形成 Quorum 选出 Leader 并提交事务，少数派由于无法达到 Quorum 而只能等待或停止服务。一个 N 节点集群可以容忍 (N-1)/2 个节点故障。为配合 Quorum，生产环境通常部署奇数个节点（3、5、7），因为奇数节点在相同容错能力下使用更少的节点。例如 3 节点集群可容忍 1 个节点故障，5 节点可容忍 2 个。

半数以上原则是分布式共识的基础，它保证了"两个分区最多只有一个拥有多数票"，从而杜绝双主。脑裂的直接危害是两份数据同时被写入，破坏一致性；Quorum 通过多数裁决从机制上排除了这种可能。部署奇数节点是为了在相同容错下节省节点数，避免 4 节点与 3 节点相同的容错能力。

• Watch 的一次性通知特性
• Session 超时与心跳
• 会话过期对临时节点和 Watch 的影响

ZooKeeper 的 Watch 是"一次性"的：客户端对某节点注册 Watch 后，当该节点发生数据变化或子节点变化时，客户端只会收到一次通知，收到后该 Watch 即失效，需要客户端手动重新注册。这要求客户端在收到事件后必须重新注册 Watch 才能继续监听，否则会丢失后续事件。会话（Session）是客户端与服务器之间的连接状态，客户端通过心跳（默认 2/3 的 sessionTimeout 超时未有心跳）维持会话。当会话超时（会话过期）时，服务器会删除该客户端创建的所有临时节点，并触发相关 Watch 通知。客户端重连时不保证恢复到同一会话，可能因会话过期而丢失临时节点。

Watch 的一次性设计是为了简化服务器的事件管理，避免长期维护事件订阅状态，但给客户端带来"事件后重注册"的复杂度。会话超时是临时节点失效的触发条件，因此心跳的及时性直接影响协调语义的可靠性。工程上要注意重连后会话可能已过期，需重新评估锁/Leader 状态。

• Leader 选举的触发与过程
• 崩溃恢复阶段的数据对齐
• 事务日志的持久化与同步

ZAB 协议主要分为三个阶段：发现（Discovery）、同步（Synchronization）、广播（Broadcast）。Leader 选举在集群启动或旧 Leader 失效（多数节点无法连接 Leader）时触发，通过投票选出拥有最新事务（最大的 zxid）的节点作为新 Leader。崩溃恢复阶段，新 Leader 会收集所有 Follower 的已提交事务记录，找出自己与 Follower 之间的数据差异，并通过差异同步（发送缺失的历史事务）使所有节点数据一致，同时对尚未提交的事务进行回滚或补齐。广播阶段则是正常的事务两阶段提交。整个过程保证：任何被提交的事务在故障后都不会丢失，且未提交的事务不会在新的状态下被错误应用。

ZAB 的核心设计是"以 Leader 的 zxid 为准进行数据对齐"，选出 zxid 最大的节点作为 Leader 能保证 Leader 拥有所有已提交事务的完整数据。崩溃恢复的差异同步保证了故障后数据不丢失、不重复，这是 ZK 强一致性的根基。

• 会话的建立与心跳机制
• 会话超时的判定与处理
• 临时节点随会话失效的语义

客户端创建 ZooKeeper 对象时通过握手建立会话，并获得一个全局唯一的 sessionId，服务器为会话分配超时时间。会话存活通过客户端定期发送心跳（Ping 或其他请求）维持，配置的 sessionTimeout 是服务器判定会话过期的时间窗口。如果客户端在 sessionTimeout 内未收到来自服务器的任何消息（跟随服务器的心跳），则判定会话超时。一旦会话过期，服务器会删除该会话创建的所有临时节点，并触发相应 Watch。客户端重连时，如果新的连接仍在原会话有效期内且服务器未标记会话过期，则可以恢复原会话（sessionId 不变）；若会话已过期，则会建立新会话，原临时节点已被删除，客户端需要重新执行协调逻辑。

会话超时是临时节点释放的触发条件，也是客户端意外断开后锁自动释放的实现基础。重连恢复与否取决于会话是否在超时窗口内，这导致客户端无法简单假设"重连即恢复原状态"。工程上应监听连接状态事件，在会话过期后重新初始化协调资源。

• 一次性通知与重注册
• 事件顺序保证
• 事件丢失的成因与处理

ZK Watch 是"一次性"的，事件触达客户端后即失效。Watch 的通知顺序与数据变更顺序一致，即服务器按事务顺序触发 Watch，客户端按接收顺序处理，同一节点的事件不会乱序。但存在"丢失窗口"：如果客户端在设置 Watch 之后、事件发生之前有操作间隙，或收到事件后未及时重注册，就可能漏掉后续事件。工程上必须采用"先注册监听，再读取数据"的顺序，避免先读后监听的竞态；收到事件后立即重新注册 Watch 再处理业务，确保连续监听。由于 Watch 是异步事件，客户端还应处理连接状态变化（如 SessionExpired、Disconnected）时重新注册所有 Watch。

Watch 的丢失风险来自"一次性"与"异步通知"的组合，客户端必须把"重注册"作为事件处理的第一步，并保证注册与读取的原子顺序。这是 ZK 客户端编程中最常见的坑之一，框架（如 Curator）通过缓存与重注册机制封装了这部分复杂度。

• LeaderLatch 与 LeaderSelector 的选主机制
• 选主回调与持续监听
• 与分布式锁的语义差异

LeaderLatch 和 LeaderSelector 都是 Curator 提供的 Leader 选举 API。LeaderLatch 是"一次性选主"：参与者尝试成为 Leader，通过 await() 阻塞等待成为 Leader，或通过监听器感知 Leader 变化，适合"谁成为主就执行一次性任务"的场景，但需要手动管理竞选重新参与。LeaderSelector 是"持续选主"：提供 takeLeadership() 回调，当节点成为 Leader 时回调执行，回调返回后自动释放 Leadership 并重新参与竞选，适合"持续协调"（如定时任务调度、部分任务执行）的场景。InterProcessMutex 是互斥锁，强调的是"同一时刻只有一个线程持有临界区"，本质是选举的特例（编号最小的节点）。选主侧重"谁负责执行"，锁侧重"谁持有资源访问权"。

三者底层都依托临时顺序节点，但语义不同：LeaderLatch 适合一次性委派，LeaderSelector 适合持续循环的 Leader 任务，InterProcessMutex 适合临界区互斥。选主 API 提供回调机制，锁 API 提供加锁/解锁方法，应根据业务意图选择。

• 分布式锁、服务注册、配置管理的实现
• ZK 的写性能瓶颈
• 会话数与连接数的限制

ZK 的典型应用包括：分布式锁（临时顺序节点）、服务注册与发现（临时节点表示在线实例，Watch 感知上下线）、配置管理（持久节点存配置，Watch 感知变更）。但随着集群规模增大，ZK 面临明显限制：一是写性能瓶颈，所有写都经过 Leader 串行广播，吞吐受限于 Leader 的刷盘能力，无法水平扩展写；二是连接与会话数量限制，每个客户端占用一个连接与会话，服务端默认最大连接数（maxClientCnxns）有限，大规模实例会耗尽连接；三是 Watch 风暴，大量实例对同一节点设置 Watch，节点变更时会产生海量通知；四是数据量限制，单节点数据默认 1MB，不适合存储大配置。因此服务注册发现等高频场景正向 etcd、Nacos 等更现代的系统迁移。

ZK 是"强一致但弱扩展"的协调器，适合低频、小数据、高可靠性的协调场景（如 Kafka 的元数据、锁、选主），不适合高频服务注册和大数据存储。工程上应把 ZK 部署在中低规模的集群，或用更贴合云原生的 etcd/Nacos 替代高频场景。

• 临时顺序节点的创建
• 最小节点持锁与排队
• 监听前一个节点规避惊群

公平锁实现：每个客户端在锁路径下创建临时顺序节点，如 /lock/lock_0000000001。然后客户端获取所有子节点，判断自己是否是最小编号节点，若是则获得锁；若不是，则监听紧邻自己前一个编号的节点（而非监听所有节点），当前一个节点被删除（持锁者释放）时，客户端重新检查自己是否成为最小节点。由于顺序节点的编号按创建顺序严格递增，先创建节点的客户端总是先获得锁，实现了 FIFO 公平性。同时只监听前一个节点，避免了"惊群效应"——即所有等待者同时被唤醒去抢锁的浪费。

公平性来源于"临时顺序节点"的单调递增编号，先到者先得；高效性来源于"只监听前一个节点"，把唤醒从 O(N) 广播降为 O(1) 链式传递。这是 ZK 分布式锁的标准实现，也是 Curator 的 InterProcessMutex 底层逻辑。

• Znode 数据大小限制（1MB）
• 大节点对性能的影响
• Watch 数量与连接数

ZooKeeper 默认限制单个 Znode 的数据大小不超过 1MB（可通过 jute.maxbuffer 调整），建议实际使用远小于此值。大的 Znode 会导致：一是网络传输开销大，写操作需在 Leader 和 Follower 之间同步大块数据；二是同步时间变长，事务提交延迟上升；三是内存占用增加。性能注意点包括：控制 Watch 数量（避免对同一节点海量 Watch）、控制连接数（每个客户端一个连接）、避免频繁对同一节点做大量小写入（写是串行的）、使用批量操作减少 RPC 次数、关闭不必要的 debug 日志。ZK 适合小数据协调，不适合存储大配置或大数据。

1MB 的限制本质是为了保证广播和同步的低延迟，ZK 的设计哲学是"协调元数据"而非"数据存储"。工程上应把配置/数据拆分到多个小节点，或用外部存储承载大数据，仅用 ZK 存元数据。

• Leader/Follower/Observer 的角色分工
• 读写路由与线性一致性
• Observer 的扩展读能力

ZooKeeper 集群中，Leader 负责处理所有写请求并广播事务，Follower 参与投票（Voting）并处理读请求，Observer 不参与投票、只接收 Leader 的提交广播并处理读请求，用于扩展读能力而不影响写入性能。写模型是线性一致的：所有写请求由 Leader 统一处理，按 zxid 顺序广播提交，保证写操作全局有序。读模型方面，Follower/Observer 可以本地处理读请求，但读到的可能是"稍旧"的数据（读不一定线性一致），因为读请求可能落在尚未同步最新事务的节点上。因此 ZK 的写是线性一致、读是最终一致（默认）。如需强一致读，可启用 sync 后读或读 Leader。

写线性一致由 Leader 串行 + zxid 排序保证；读可能读到旧数据是因为 Follower 的数据同步有延迟。Observer 的引入是为了在不增加投票节点（避免降低写入性能）的情况下水平扩展读能力。生产环境读多写少时可加 Observer 提升读吞吐。

• Kafka 中 ZK 的职责（broker 元数据、Controller 选举）
• HDFS 中 ZK 的职责（NameNode HA、FailoverController）
• ZK 与主系统的职责边界

在 Kafka 中，ZK 早期承担 broker 注册、Topic 元数据、消费者组偏移量（早期版本）以及 Controller（分区副本的 Leader）选举等职责，broker 通过临时节点注册并在启动时向 ZK 注册，Controller 通过 ZK 选主。在 HDFS 中，ZK 用于 NameNode 的高可用（HA）：两个 NameNode 通过 ZK 的临时节点进行活性选举，FailoverController 通过 ZK 实现故障转移，active/standby 状态由 ZK 临时节点标记。职责边界在于：ZK 只承担"协调元数据"和"故障转移决策"，不承载具体业务数据（Kafka 的日志数据在 broker 上，HDFS 的块数据在 DataNode 上）。注意点是 ZK 单点瓶颈、连接数限制，因此 Kafka 新版本（KIP-500）正在移除对 ZK 的依赖，改为内置 KRaft 元数据。

ZK 在这些系统中扮演"协调神经中枢"，负责状态共识与故障转移，但数据面由各系统自身承担，这体现了"控制面与数据面分离"的设计。随着 KRaft 等技术的成熟，ZK 正逐步被各个系统内置的共识机制取代。

• 常用 4lw 命令及含义
• 监控指标（延迟、连接数、znode 数）
• 启停 4lw 命令的配置

ZooKeeper 提供 4lw 命令用于运维诊断，通过 telnet/nc 连接客户端端口发送命令即可。常用命令：stat（查看节点状态，含连接数、znode 数、模式 Leader/Follower）、ruok（返回 "imok" 表示节点健康，但仅表示进程存活，不反映集群状态）、mntr（输出监控指标，如 zk_server_state、zk_znode_count、zk_outstanding_requests、zk_packets_received 等，适合监控系统采集）、envi（环境信息）、conf（配置信息）、srvr（服务器详情）、wchc（查看 Watch 详情）。新版 ZK（3.5+）出于安全考虑默认仅开启 srvr 命令，其余 4lw 命令需通过 4lw.commands.whitelist 配置白名单后才能使用。生产监控应优先用 mntr 采集指标，结合 Prometheus + Grafana 展示，并关注 leader 状态、请求延迟、outstanding 请求积压、连接数等关键指标。

4lw 命令是 ZK 运维的最直接手段，stat/srvr 用于诊断，mntr 用于监控采集。ruok 只反映进程存活，不能代替集群健康检查，需结合 Leader 状态和请求指标综合判断。