分布式协调

• Curator 的 API 封装
• LeaderLatch 与 LeaderSelector 的选主
• SharedLock 分布式锁

Apache Curator 是基于 ZooKeeper 的高层客户端库，封装了大量分布式协调原语。LeaderLatch：用于"选主"，多个实例竞争成为 Leader，通过一个临时节点（指定路径）的占用实现，Leader 宕机时临时节点消失、其他实例自动接管，适合"只有一个 Leader 且不关心选举过程"的场景。LeaderSelector：也是选主，但更灵活，支持"获得领导权后执行任务、释放后可再次参与选举"，并可通过回调（takeLeadership）定制领导权获得后的执行逻辑，适合"需要持续选主"的场景。SharedLock：分布式锁，基于临时顺序节点实现互斥锁，多个客户端在同一路径下创建有序临时节点，序号最小者获得锁，其他节点监听前驱节点释放后获取，公平且可重入。Curator 还提供 Cache（节点监听）、选举、分布式队列等。这些封装把 ZooKeeper 的底层 API（创建节点、监听、顺序节点）包装成易用的高级接口，是 ZK 分布式协调的主流工具。

Curator 的价值是"把 ZooKeeper 的复杂原语封装成现成的高级组件"。LeaderLatch/LeaderSelector 管选主，SharedLock 管互斥锁，基于临时/顺序节点实现，是 ZK 分布式协调的工程化基础。

• Chubby 的锁服务模型
• 对 ZooKeeper 的启发
• 两者的异同

Chubby 是 Google 内部的分布式锁服务，用于为 GFS、Bigtable 等提供分布式锁与选主。它的原始设计理念：以"文件系统式"的命名空间管理锁（类似文件/目录的层次结构），提供"锁 + 小文件数据"的存储，客户端通过租约（lease）维持锁，服务端基于 Paxos 复制保证一致性。这些设计对 ZooKeeper 有深远影响：ZooKeeper 借鉴了 Chubby 的"分层命名空间 + 节点数据 + 锁/选主"思想，形成了 ZNode 的数据模型、临时节点、顺序节点、watch 等机制；ZooKeeper 的分布式锁（基于临时/顺序节点）与选主（Leader/LeaderLatch）思路与 Chubby 一脉相承，但用更简单的 ZAB 协议替代了 Chubby 的 Paxos。差异：Chubby 面向 Google 内部、锁语义更强（强锁、租约），ZooKeeper 更通用、更轻量、被广泛开源使用。Chubby 的"锁即服务"理念直接影响了 ZK 的分布式协调能力设计。

Chubby 是 ZooKeeper 的"思想源头"：用"文件系统式命名空间 + 锁 + 租约 + 复制"提供分布式协调。ZooKeeper 借鉴了这些理念并工程化、开源化，是理解 ZK 设计由来的关键。

• ZK 在 Kafka 中的元数据管理
• KRaft 对 ZK 的替代
• 演进与影响

在传统 Kafka 架构中，ZooKeeper 承担元数据管理与协调角色：管理 broker 注册、主题（topic）分区与副本的元数据、Controller 选主（leader election）、以及部分配置。ZooKeeper 是 Kafka 集群的"元数据中心"，broker 启动时向 ZK 注册，Controller 通过 ZK 的临时节点选主，分区 leader 的变更也通过 ZK 协调。KRaft（Kafka Raft）是 Kafka 引入的新协议，用 Raft 共识替代 ZooKeeper：Kafka 在 KRaft 模式下用内置的 Raft 元数据日志（基于 Raft 的 quorum controller）管理元数据与 Controller 选主，从而移除对 ZooKeeper 的依赖。变化：KRaft 模式下 Kafka 不再需要独立的 ZK 集群，元数据与 Controller 由 Kafka 自身的 Raft 日志保证一致，简化部署、降低运维复杂度、提升可扩展性（ZK 的元数据规模限制被移除）。演进：新版本 Kafka 推荐 KRaft 模式，传统 ZK 模式逐步被淘汰。ZK 在 Kafka 中的角色从"元数据协调核心"变为"被替代的旧组件"。

ZK 在 Kafka 中是"外置元数据协调者"，KRaft 用"Kafka 内置 Raft 日志"取代它。移除 ZK 是 Kafka 的架构演进，减少依赖、简化部署、提升元数据可扩展性。

• 分布式锁的适用与局限
• 命名服务与配置中心
• 集群管理的角色

ZooKeeper 在分布式协调中有广泛应用，但各有边界。分布式锁：基于临时顺序节点实现互斥锁，适合"对一致性要求高、节点数有限"的场景；但 ZK 锁的性能受限于 ZK 集群的读写吞吐（不像 Redis 锁那样高并发），且锁的持有依赖 session（会话），会话超时可能导致锁被误释放，不适合"高频加解锁"或"要求低延迟"的场景；适合"选主、互斥资源、低频关键操作"。命名服务：ZK 用 ZNode 层次结构做服务注册发现（如 Dubbo、Nacos 早期），适合"节点数适中、需强一致"的场景；但大规模高频心跳注册会带来 ZK 压力，故大型注册中心多转向 AP 方案（如 Nacos Distro）。集群管理：ZK 用于管理集群 broker/节点状态、Controller/Leader 选主、配置下发，适合"需要强一致协调"的场景；边界是"元数据规模与写压力不能过大"。工程上 ZK 适合"强一致、低频、关键协调"，不适合"高频、海量、AP 优先"的场景。

ZK 的边界由"强一致 + 读写能力"决定：它提供强一致协调，但吞吐受限。适合锁、命名、集群管理的"关键低频"操作，不适合高频海量或 AP 场景。

• Leader 选举的角色与过程
• ZAB 协议的一致性
• 选主与数据同步

ZooKeeper 通过 ZAB 协议实现 Leader 选举与一致性。Leader 选举：集群节点通过投票选出 Leader，比较各节点的 Zxid（事务编号）与 myid，Zxid 最大（数据最新）的节点优先，其次 myid 大的节点优先；获得多数派（过半）投票的节点成为 Leader。选举机制保证新 Leader 拥有最新数据，避免日志丢失。一致性：ZAB 采用"写必须经过 Leader"的模型——写请求由 Leader 接收，通过两阶段（propose + commit）广播给 Follower，多数派确认后提交，保证所有节点按相同顺序应用事务（全序广播）；Leader 故障时触发新选举，新 Leader 通过历史同步把已提交事务补发给落后节点，保证状态一致。因此 ZooKeeper 提供强一致（线性一致）的读写，读请求可走 Leader 或 Follower（Follower 读可能读到稍旧数据，取决于是否同步点）。整个机制保证"选主不冲突 + 数据一致 + 已提交不丢"。

ZK 的选主"选 Zxid 最新"保证数据不丢，ZAB 的"Leader 全序广播 + 多数派提交"保证强一致。选举与一致性紧密耦合，是 ZK 作为强一致协调服务的核心。

• Multi 的批量操作
• 原子执行保证
• 适用场景

ZooKeeper 的 Multi 操作（multi()）允许在一个请求中批量执行多个 ZNode 操作（如 create、delete、setData、check），且这些操作以"原子"方式执行：要么全部成功，要么全部失败（任意一个失败则整体回滚，之前的操作不生效）。这保证了多个 ZNode 变更的一致性，避免了"一个请求中部分成功部分失败"造成的不一致。Multi 的原子性由 ZK 服务端保证：所有操作作为一个事务单元处理，在提交时要么全部落地要么全部不落地。适用场景：需要"同时创建关联数据"或"校验后原子更新"的场景——例如创建分布式锁时校验节点存在性再创建子节点、配置的批量更新、注册信息的原子变更等。Multi 是构建复杂分布式协调逻辑（如锁、分布式事务协调）的重要原语，Curator 的 transaction() 也封装了 Multi。

Multi 的价值是"把多个 ZNode 操作打包成原子事务"，避免"部分成功"状态。它让 ZK 能表达"要么全做要么全不做"的协调逻辑，是构建复杂协调原语的基础。

• 写请求到 Leader
• propose 与 commit 两阶段
• Follower 同步与确认

ZooKeeper 的 ZAB 写入流程：客户端把写请求发给 Leader（或经 Follower 转发到 Leader）；Leader 为请求分配一个 Zxid（事务编号）并广播 propose 给所有 Follower；Follower 收到 propose 后，将事务写入本地日志并返回 ack（确认）；Leader 收到多数派（过半）的 ack 后，认为事务已提交，广播 commit 给所有 Follower；Follower 收到 commit 后应用事务到内存数据，并返回给客户端成功。整个流程保证"多数派确认才提交"，且所有节点按 Zxid 顺序应用事务（全序），从而保证一致性。若 Leader 在提交前崩溃，新 Leader 通过历史同步（根据 Zxid 补齐未提交或已提交事务）保证不丢已提交事务。写入路径是"Leader 单点写入 + 多数派 ack + commit 广播"，与 Raft 的日志复制类似，但 ZAB 以事务（Zxid）为单位组织。

ZAB 写入是"Leader 接收 → propose → 多数派 ack → commit → 应用"。原子性来自"多数派确认"，顺序性来自"Zxid 全序"，是 ZK 强一致写的核心。

• 命名服务（服务注册发现）
• 配置中心（动态配置）
• 分布式锁（临时顺序节点）

ZooKeeper 的典型应用包括：命名服务——用 ZNode 分层结构管理服务名与地址，服务启动时创建临时节点注册，客户端通过获取节点获取服务地址，实现服务发现（如 Dubbo、早期 Nacos）；临时节点与默认 30 秒会话保证服务宕机时节点自动消失，实现自动摘除。配置中心——用 ZNode 存储配置，客户端 watch 配置节点，配置变更时 ZK 主动通知客户端，实现动态配置分发（如 Spring Cloud ZooKeeper 配置中心）；通过 watch 机制实时感知配置变化。分布式锁——基于临时顺序节点：多个客户端在同一路径下创建顺序临时节点，用序号最小者获得锁，其他监听前驱节点，前驱删除后获取锁，实现公平互斥锁（如 Curator InterProcessMutex）；临时节点保证持有者崩溃时锁自动释放，避免死锁。三者都利用 ZK 的"强一致 + 临时节点 + watch + 顺序节点"特性，是 ZK 作为分布式协调核心的典型用途。

ZK 的三大典型应用都依托其核心特性：命名服务用临时节点+层次，配置中心用 watch，分布式锁用临时顺序节点。理解这些应用即理解 ZK 原语的价值。

• Consul 的服务注册与发现
• 健康检查方式
• 与 DNS/HTTP 集成

Consul 是一个服务发现与配置中心，其服务发现机制：服务实例启动时向 Consul 注册（服务名、地址、端口、健康检查），Consul 通过 Raft 存储服务元数据；客户端通过 Consul 查询服务名获取实例列表，并通过 DNS 或 HTTP API 解析。健康检查（Health Check）是关键：Consul 支持多种健康检查（HTTP 探活、TCP 连接、脚本检查、TTL 续约），定期检查服务实例的存活与健康状态；不健康的实例会被标记并从可用列表中剔除，避免客户端路由到故障节点。Consul 的发现与健康检查结合：客户端可查询"仅健康"的实例（如 DNS 只返回健康实例），系统自动摘除故障节点。Consul 还支持服务 mesh（Connect）、KV 配置、多数据中心。与 etcd 相比，Consul 更偏重"服务发现 + 健康检查 + 配置"，而 etcd 偏重"强一致 KV"。健康检查是 Consul 保证服务可用性的核心。

Consul 的服务发现核心是"注册 + 健康检查 + 查询"，健康检查决定"哪些实例可用"。它与 etcd 的差异在于偏重服务发现与健康检查，而非纯 KV。

• 使用方式与回调
• 释放后是否可再参与
• 适用场景

LeaderLatch 与 LeaderSelector 都是 Curator 的选主组件，但差异明显。LeaderLatch：简单"竞争领导权"，通过临时节点占用实现，多个实例竞争，只有一个成为 Leader；使用上调用 start() 竞争、await() 阻塞等待获权、close() 释放；Leader 宕机后自动切换，但 LeaderLatch 释放后不自动重新参与竞争（需要重新 start）。LeaderSelector：更灵活，通过回调 takeLeadership() 在获得领导权后执行任务，任务结束后可自动重新参与选举（autoRequeue 控制是否重新排队）；适合"需要持续选主、领导权切换频繁"的场景。差异核心：LeaderLatch 是"抢占式单次",LeaderSelector 是"回调式可循环参与"。适用场景：只需"谁是 Leader"且不关心后续用 LeaderLatch（简单）；需要"获得领导权后执行任务、任务结束可再竞选"用 LeaderSelector（更常用）。两者都基于临时节点，宕机自动释放。

差异在"获权后做什么"：LeaderLatch 只标志"我是 Leader"，LeaderSelector 用回调执行任务并可循环参与。选 LeaderLatch 求简单，选 LeaderSelector 求可控的选主循环。

• 注册中心的接入
• 服务注册与发现
• 心跳与健康检查

Spring Cloud Zookeeper 与 Spring Cloud Consul 分别在 Spring Boot 3.5+ 中作为服务注册发现组件。Zookeeper 版本：引入 spring-cloud-starter-zookeeper-discovery，服务启动时通过 ZookeeperServiceRegistry 向 ZK 注册（在 services 路径下创建临时节点，记录服务名、实例地址、端口），客户端通过 ZookeeperDiscoveryClient 获取服务列表实现发现；ZK 通过会话/临时节点保证实例宕机自动摘除。Consul 版本：引入 spring-cloud-starter-consul-discovery，服务启动时通过 ConsulServiceRegistry 向 Consul 注册（服务名、实例、健康检查），Consul 定期健康检查，客户端通过 ConsulDiscoveryClient 发现健康实例；Consul 支持健康检查自动剔除非健康实例。两者都提供 DiscoveryClient 抽象，与 Spring Cloud LoadBalancer/Feign 结合，实现服务路由与负载均衡。配置上通过 spring.cloud.zookeeper.* 或 spring.cloud.consul.* 指定注册中心地址、是否注册、健康检查等。实现机制都是"服务注册 + 心跳/健康检查 + 发现查询"。

两者实现的本质相同：服务启动注册、健康检查保活、客户端按需发现。区别在底层存储（ZK vs Consul）与健康检查方式（ZK 会话 vs Consul 主动检查），都通过 DiscoveryClient 抽象向 Spring Cloud 开放。

• ZK 锁（临时顺序节点）与 Redis 锁（setnx）
• 两者的可用性与一致性
• 羊群效应及防范

ZK 分布式锁：基于临时顺序节点，多个客户端创建顺序临时节点，序号最小者获锁，其他监听前驱节点，前驱删除后获锁；优点是一致的可信（临时节点 + 会话，客户端崩溃自动释放锁，不会死锁），缺点是吞吐较低（ZK 写性能限制）、羊群效应（大量客户端同时监听、释放时同时唤醒）。Redis 分布式锁：基于 SET key value NX PX（setnx + 过期时间），获取锁设置过期时间，超时自动释放；优点是高并发、低延迟，缺点是锁的可靠性依赖 Redis 与过期时间（持有者崩溃可能锁未过期需等待，或过期时间内未完成导致锁过期误判），需用 RedLock 等提升可靠性。羊群效应：ZK 锁中，若锁释放时唤醒所有等待者，它们同时竞争创建节点，造成大量请求与性能抖动。防范：ZK 锁用"监听前驱节点"而非"监听根节点"——每个等待者只监听自己的前驱，前驱释放时只有下一个等待者被唤醒，避免所有等待者同时竞争（这是 ZK 锁天然的羊群防范）；Redis 锁则通过"自旋 + 随机退避"或"等待队列"减少同时竞争。总结：ZK 锁更可靠、天然防羊群，Redis 锁更高效、需注意过期与可靠性。

ZK 锁强一致（临时节点+会话）但慢，Redis 锁快但需处理过期与可靠性。羊群防范上，ZK 用"监听前驱"链式唤醒，Redis 用自旋退避。选型看"一致性 vs 性能"。

• ZooKeeper 的角色与架构
• ZAB 的选举、发现、同步、广播
• 一致性保证

ZooKeeper 的架构是"Leader + Follower + Observer"的集群：Leader 负责接收写请求、广播与提交；Follower 参与投票并处理读请求；Observer 只读不投票，用于扩展读能力。ZooKeeper 通过 ZAB 协议（ZooKeeper Atomic Broadcast）保证一致性，ZAB 分为：Leader 选举（选出 Zxid 最新的 Leader）、发现（Follower 与 Leader 同步数据）、同步（Leader 把已提交事务补发给 Follower）、广播（Leader 以两阶段 propose+commit 广播新事务）。ZAB 保证全序广播——所有节点按相同顺序应用事务，配合多数派确认实现强一致。客户端通过 Session 连接，watch 机制监听节点变化。ZooKeeper 的架构本质是"单 Leader 写 + 多副本读 + 多数派共识"，提供强一致、高可用的分布式协调服务。ZAB 与 Raft 类似，但以事务（Zxid）为单位组织。

ZK 架构是"Leader 写、Follower 读、Observer 扩展"，ZAB 是"选举+发现+同步+广播"的全序广播协议。理解架构与 ZAB 即理解 ZK 的一致性与可用性来源。

• InterProcessMutex 的机制
• 顺序节点与监听前驱
• 可重入与释放

Curator 的 InterProcessMutex 是基于 ZooKeeper 的分布式互斥锁，机制：客户端在指定锁路径下创建临时顺序节点（_c_<seq>），所有客户端按序号排序，序号最小者获得锁；其他客户端监听自己的前驱节点，当前驱删除（锁释放）时，下一个客户端竞争获取。这种"监听前驱"的链式结构避免了羊群效应（每次释放只唤醒一个等待者）。InterProcessMutex 支持可重入（同一线程可多次 acquire，内部计数），释放时删除对应节点，临时节点保证客户端崩溃时锁自动释放（不产生死锁）。获得锁后执行临界区，最后必须 release 释放。相比 Redis 锁，InterProcessMutex 一致性强（ZK 强一致）、无过期误判（临时节点 + 会话），但吞吐较低。适合"并发要求不高、一致性要求高"的互斥场景。Curator 还提供 InterProcessReadWriteLock（读写锁）、InterProcessSemaphoreMutex 等。

InterProcessMutex 的核心是"临时顺序节点 + 监听前驱"，实现公平、可重入、防羊群的分布式锁。临时节点保证崩溃自动释放，是其可靠性的关键。

• etcd 的 Raft 与 ZK 的 ZAB
• API 与数据模型
• 云原生场景的选型

etcd 与 ZooKeeper 都是强一致分布式协调系统，但实现与定位不同。协议：etcd 用 Raft（etcd-raft），ZooKeeper 用 ZAB；两者都是"Leader 写 + 多数派提交 + 日志复制"，但 Raft 更易实现、etcd-raft 更模块化，ZAB 以事务（Zxid）为单位。数据模型与 API：etcd 提供简单的 Key-Value + MVCC + watch（revision 版本）+ lease，API 简洁（gRPC/HTTP）；ZooKeeper 提供 ZNode 层次结构 + watch，API 更偏文件系统风格。云原生场景：etcd 是 Kubernetes 控制面元数据存储的标准（存储集群配置、服务状态），适合"强一致 KV + watch + lease"的云原生场景，且 API 简洁、与 K8s 生态深度集成；ZooKeeper 在 Kafka 等传统分布式系统中广泛应用，但在云原生场景逐渐被 etcd 取代（Kafka 已用 KRaft 移除 ZK）。取舍：etcd 更贴合云原生（K8s、配置、服务发现），ZooKeeper 在传统"分布式锁/选主/队列"场景仍有适用。总体云原生优先选 etcd，传统协调场景 ZK 仍可用。

etcd 与 ZK 都强一致，差异在"协议（Raft vs ZAB）、数据模型（KV vs ZNode）、生态（云原生 vs 传统）"。云原生场景 etcd 因 K8s 集成与简洁 API 更胜出。

• 定位（服务发现 vs KV）
• 健康检查与服务 mesh
• 选型场景

Consul 与 etcd 都是分布式协调系统，但定位不同。Consul 定位"服务发现 + 配置中心 + 健康检查 + 服务 mesh"：提供 DNS/HTTP 服务发现、健康检查（自动摘除故障实例）、多数据中心、KV 配置、Connect 服务网格；基于 Raft 保证一致性。etcd 定位"强一致 KV 存储"：API 简洁（Key-Value + watch + lease + 事务），是 Kubernetes 控制面元数据存储，偏"基础存储"而非"服务发现"。工程对比：Consul 更"开箱即用"的服务发现（内置健康检查、DNS、服务 mesh），适合需要服务发现 + 健康检查 + 配置一体化的场景；etcd 更"基础、灵活"的 KV 存储，适合需要强一致 KV + watch 的自建系统（如 K8s、自研配置中心）。数据模型：Consul 有服务/健康检查/节点概念，etcd 是纯 KV。选型：若需要"服务发现 + 健康检查 + 配置"一体化选 Consul；若需要"强一致 KV + watch"作为底层存储选 etcd。都基于 Raft，但面向的工程场景不同。

差异核心是"定位"：Consul 是"服务发现 + 健康检查 + 配置"的完整方案，etcd 是"强一致 KV"的基础存储。选型取决于需要"完整服务发现"还是"底层 KV 能力"。

• CuratorFramework 的构建
• 重试策略类型
• 连接管理

Curator 客户端通过 CuratorFrameworkFactory 构建：指定 ZK 连接串（connectString）、会话超时（sessionTimeout）、连接超时（connectTimeout）、以及重试策略。Curator 的重试策略是健壮连接的关键：ExponentialBackoffRetry（指数退避重试，间隔按指数增长，最多 N 次）、RetryNTimes（固定次数重试）、RetryOneTime（单次重试）、RetryForever（无限重试，用于后台任务）、InterProcessMutex 等还依赖重试。Curator 通过 RetryPolicy 抽象，重试策略决定"连接失败/操作失败时如何重试"。构建后 start() 启动客户端，close() 关闭。Curator 管理连接状态（连接/断开监听），并封装了高级组件（LeaderLatch、InterProcessMutex、Cache 等）。重试策略的作用是：ZK 暂时不可用或网络抖动时，客户端能自动重试连接与操作，避免一次性失败，保证协调环节的健壮性。选择重试策略需权衡"重试次数与间隔"（避免过大重试风暴）与"任务重要性"（后台任务可无限重试）。

Curator 客户端的核心是"构建 + 重试策略 + 连接管理"。重试策略决定故障时的韧性，指数退避是常用选择，避免瞬时故障导致的长任务失败。

• 动态配置的能力
• 配置变更与重启
• 节点增删与成员变更

ZooKeeper 的 DynamicConfigFile 是动态配置机制，允许在运行中修改集群配置（如成员列表、集群参数）而无需重启所有节点。ZooKeeper 3.5+ 支持动态 reconfiguration：通过 reconfig 命令或 Admin API 动态增删节点、修改法定人数（quorum）配置、调整参数，配置变更以"配置版本"管理并持久化到动态配置文件中（dynamicConfigFile）。相比静态配置文件（zoo.cfg），动态配置可在运行时更新，支持在线扩容/缩容、调整 quorum 行为，提升运维灵活性。使用需在配置中启用动态配置（dynamicConfigFile 指定文件），配合 reconfig 只允许在某些节点执行（默认仅 leader 或指定节点）。配置变更会通过 ZAB 传播，保证所有节点配置一致。工程上适合"需要在线调整集群成员/参数"的场景，避免停机维护。

DynamicConfigFile 让 ZK 集群配置"在线可改"，用 reconfig 动增删节点与参数，配置变更经 ZAB 一致传播。它解决了"改配置需重启"的运维痛点。

• 常用四字命令
• 监控与状态查询
• 运维用途

ZooKeeper 的 Four Letter Words（四字命令）是用于运维/监控的简短命令，通过 telnet 或 nc 发送到 ZK 端口（默认 2181）执行。常用命令：ruok（返回 "imok" 表示存活）、stat（查看服务器状态、连接数、模式、Zxid 等）、srvr（查看服务器概要信息）、dump（查看会话与临时节点）、wchs（watch 数量）、mntr（监控指标，如数节点数、连接数、选主信息）、conf（查看配置）、cons（查看客户端连接）、envi（环境信息）、srst（重置统计）、crst（重置让计数器）。这些命令用于快速检查 ZK 集群健康、性能与状态，是运维排障的重要工具。注意 mntr 提供机器可读的监控指标，便于接入监控系统；ruok/stat 用于快速存活与状态检查。四字命令默认可用，但也可通过 4lw.commands.whitelist 配置白名单限制，提升安全性。

四字命令是 ZK 的"运维诊断工具"，用 ruok/stat/mntr 等快速查询存活、状态与监控指标。理解它们有助于日常运维与排障。

• JMX 的启用
• 核心监控指标
• 接入监控系统

ZooKeeper 提供 JMX（Java Management Extensions）监控，通过 Java 的 MBean 暴露运行时指标，用于集成监控系统（如 Prometheus、JConsole、Grafana）。启用 JMX：在 zoo.cfg 中配置 JMX 端口（-Dcom.sun.management.jmxremote 或 4lw.commands 相关），或通过 zookeeper.jmx.log4j.disable 等控制。核心指标：mntr 对应的指标（如 zk_num_alive_connections 活跃连接数、zk_znode_count 节点数、zk_watch_count 监听数、zk_outstanding_requests 待处理请求、zk_pending_syncs、zk_avg_latency 平均延迟、zk_queries_per_second QPS、zk_leader_followers 等），以及 zk_server_state（leader/follower 状态）。这些指标反映集群健康、性能与负载。接入方式：通过 JMX 暴露的 MBean 由 Prometheus JMX exporter 抓取，或通过 mntr 命令解析，再接入 Grafana 展示与告警。监控重点是"连接数、节点数、延迟、QPS、待处理请求、leader 状态"，用于发现性能瓶颈、分区、负载异常。

ZK 的 JMX 把"连接数、节点数、延迟、QPS、待处理请求、leader 状态"等指标暴露给监控系统。核心是"把运行态指标可观测化"，用于容量与健康管理。

• Observer 的角色
• 读扩展与不投票
• 适用场景

ZooKeeper 的 Observer 节点是"只读、不参与投票"的节点：它同步 Leader 的数据（接收提交的事务），但不参与选主投票、也不计入法定人数（quorum），因此不增加写路径的投票开销。Observer 的作用是扩展读能力：当读请求量大、Follower 读压力高时，通过增加 Observer 节点提升读吞吐，而不会因增加投票节点拖慢写性能（因为 Observer 不计入 quorum）。Observer 的容错：它故障不影响集群可用性（不是 quorum 成员），但也不提供选主能力。适用场景：读多写少、需要水平扩展读能力的集群；跨数据中心部署时，可在远端数据中心部署 Observer 提供本地读，减少跨机房延迟。部署 Observer 需在配置中声明（server.N=地址:端口:observer），并配置 peerType=observer。Observer 是"读扩展 + 不拖慢写"的平衡方案。

Observer 的价值是"扩展读但不影响写"——它同步数据却不参与投票，从而在增加读能力的同时不增加 quorum 开销。适合读密集型与跨机房读场景。

• Session 的建立与超时
• ACL 权限控制
• 临时节点与会话关联

ZooKeeper 的 Session 是客户端与服务器之间的连接会话：客户端连接后建立 Session，通过心跳维持；Session 有超时时间（sessionTimeout），若超时未收到心跳，会话失效，关联的临时节点（ephemeral node）会被自动删除。Session 机制是 ZK 分布式锁可靠性的基础（客户端崩溃 → 会话超时 → 临时节点消失 → 锁自动释放）。ACL（Access Control List）是权限控制：ZK 节点可设置 ACL，控制客户端对节点的操作权限（读、写、创建子节点、删除、管理），ACL 基于认证信息（如 digest 用户名密码、world 所有人、ip 白名单、auth 认证用户）。ACL 用于保护敏感节点（如配置、锁路径）不被未授权访问/修改。Session 与 ACL 结合：客户端通过认证（addAuthInfo）建立身份，ACL 据此授权。工程上，Session 超时管理影响分布式锁的可靠性，ACL 保护数据安全，都是 ZK 使用的重要配置。

Session 管"连接生命周期"（超时删临时节点），ACL 管"访问权限"。Session 超时是临时节点与锁自动释放的基础，ACL 保护节点安全，二者是 ZK 可靠与安全的关键。

• ZNode 的数据模型
• Watcher 的监听与通知
• 一次性与触发

ZooKeeper 通过 ZNode 组织数据：ZNode 是数据节点，可存储数据（如配置、状态），具有层次结构（类似文件系统），类型包括持久节点、临时节点、顺序节点。Watcher 是 ZK 的监听机制：客户端可对某个 ZNode 注册 Watcher，当该节点发生变化（数据变更、子节点变化、节点删除）时，ZK 服务端会通知客户端，客户端收到事件后做出响应。Watcher 的特点：一次性（触发一次后失效，需重新注册才能继续监听）、轻量（只通知"变了"，不携带具体数据，客户端需再查询）、基于 ZK 的连接（变更由服务端推送）。Watcher 用于实现配置动态更新、服务发现、分布式锁的唤醒（如监听前驱节点）等。注意 Watcher 是一次性的，监听循环需在事件回调中重新注册，否则会漏监听。Watcher 机制让 ZK 具备"主动通知"能力，是实现动态协调的基础。

ZNode 是"数据载体"，Watcher 是"变更通知"。Watcher 一次性 + 轻量通知的特点决定了客户端需在回调中重新注册，是理解 ZK 监听编程的关键。

• 持久节点
• 临时节点
• 顺序节点

ZooKeeper 的 ZNode 分为三类（可组合）。持久节点（Persistent）：数据持久保存，客户端会话断开后仍存在，需显式删除，适合存储配置、服务元数据等长期数据。临时节点（Ephemeral）：与客户端会话绑定，会话结束（超时/断开）时自动删除，适合服务注册、分布式锁、Leader 占位（宕机自动消失）。顺序节点（Sequential）：节点创建时自动追加一个单调递增序号（如 _c_0000000001），保证节点创建顺序，适合分布式锁（按序号排序竞争）、队列等。三类可组合：持久顺序节点（Persistent Sequential）、临时顺序节点（Ephemeral Sequential）——后者是分布式锁的基础（临时保证宕机释放，顺序保证公平竞争）。ZNode 还可设置数据（最大 1MB）与 ACL。理解类型是构建 ZK 协调逻辑的前提。

ZNode 类型决定了"生命周期与顺序"：持久=长期、临时=随会话、顺序=有序。组合出"临时顺序"用于锁与选主，是 ZK 最常用的协调原语。

• Zxid 作为事务编号
• 快照恢复的基准
• diff 与 trunc 的增量同步

Zxid（ZooKeeper Transaction ID）是 ZooKeeper 的全局事务编号，用于标识每次写操作，在快照恢复与增量同步中起关键作用。快照恢复：ZK 定期把内存数据落盘为快照（snapshot），快照记录对应某个 Zxid；重启时加载快照，再根据 Zxid 从快照之后的日志（transaction log）重放事务，恢复到最新状态，避免丢失快照后的更新。增量同步（diff）：新节点或落后节点与 Leader 同步时，Leader 根据双方 Zxid 判断差异，把对方缺失的（Zxid 更大）已提交事务通过 diff 增量同步给落后节点，无需全量快照。truncate（trunc）：当某节点含有多余的、未提交或已被最新 Leader 丢弃的事务（Zxid 超过 Leader 的已提交范围），Leader 会指示其 truncate 截断到 Leader 的 Zxid，删除多余事务，保证一致性。三者都依赖 Zxid 的"全局有序"来定位"哪部分数据需要重放/同步/截断"。Zxid 是 ZK 数据一致性的基准。

Zxid 是"全局有序的事务编号"，快照恢复用它定位重放起点，diff 用它定位缺失范围，trunc 用它定位多余范围。理解 Zxid 即理解 ZK 的数据同步机制。

• Zxid 的高低位结构
• epoch 与 counter 的作用
• myid 在选举中的作用

ZooKeeper 的 Zxid 是 64 位 long，结构为：高 32 位是 epoch（Leader 任期/代），低 32 位是 counter（当前任期内的递增序号）。epoch 用于区分不同的 Leader 任期——每次新 Leader 选举产生，epoch 递增，从而区分"不同任期的事务"；counter 是当前任期内的单调递增序号，保证同一任期内事务顺序。Zxid 整体单调递增，用于全序排序与数据最新判断。myid（my id）是每个节点的唯一数字标识（配置文件中设置），在选举中起关键作用：当多个节点 Zxid 相同时，myid 大的节点优先成为 Leader（作为 tie-breaker）。myid 还用于日志、节点身份标识。综合：Zxid 的 epoch+counter 结构提供"任期区分 + 顺序"，myid 提供"节点唯一标识 + 选举决胜"，二者共同构成 ZK 选主与数据一致的基础。

Zxid 的高 32 位 epoch 区分 Leader 任期、低 32 位 counter 保证任期内顺序；myid 是节点唯一标识并作为选主决胜。理解二者是理解 ZK 选主与日志排序的关键。

• chroot 的含义
• 客户端视角隔离
• 应用场景

ZooKeeper 的 chroot（change root）隔离机制：客户端在连接串中指定一个根路径（如 host:port/app1），则该客户端只看到该路径下的子树，相当于为客户端"重定根"，把其视角限制在指定命名空间内。通过 chroot，多个应用/租户可以共享同一个 ZK 集群，但各自隔离在独立的根路径下，互不干扰（一个应用看不到、也改不动其他应用的节点），从而实现多租户隔离与命名空间管理。chroot 的实现：客户端把连接串中的路径作为"根"，创建的节点、监听的路径都基于该根，服务端仍按绝对路径处理但客户端视角被限定。它不改变服务端的数据隔离逻辑（仍是同一棵 ZNode 树），但能防止客户端误操作其他租户的数据。应用场景：多个团队共享一个 ZK 集群时，用 chroot 隔离各团队的命名空间；或为不同环境（dev/test/prod）分配不同根路径。chroot 是低成本的多租户隔离方案。

chroot 是"客户端视角的根路径隔离"：通过连接串指定根路径，让客户端只访问该子树，实现多租户共享 ZK 集群的隔离。它简单但有效，适合共享 ZK 的场景。

• Lease 与 KeepAlive
• MVCC 与 revision
• compact 清理历史版本

etcd 的 Lease（租约）是一种绑定 key 的"过期时间"机制：key 可关联一个 Lease，Lease 有 TTL，客户端通过 KeepAlive（续约）定期续期，防止 Lease 过期；若客户端停止续约，Lease 到期后其关联的 key 被自动删除。Lease 常用于服务注册、锁、leader 租约等（如 Kubernetes 租约、分布式锁的自动释放）。MVCC（多版本并发控制）：etcd 的每个 key 保存多个版本，每次写入产生一个全局递增的 revision（版本号），可读取任意历史版本；watch 通过监听 revision 变化感知 key 更新。历史版本会不断累积，占用存储，需通过 compact（压缩）清理：compact 指定一个 revision，丢弃该 revision 之前的历史版本，只保留最新版本，控制存储增长。Lease/KeepAlive 管"生命周期"，MVCC/revision 管"版本与历史"，compact 管"历史清理"。三者共同支撑 etcd 的租约、watch 与存储管理。

Lease 管"过期自动删除"，MVCC 管"多版本历史 + watch"，compact 管"清理历史"。理解它们才能正确使用 etcd 的租约、watch 与存储容量管理。

• MVCC 多版本存储
• watch 的 revision 监听
• 从某 revision 监听历史事件

etcd 的 MVCC 多版本存储：每个 key 的每次写入都会产生一个新版本（revision），旧版本保留，可读取任意历史版本；revision 是全局单调递增的版本号，标识每次写操作。watch 机制基于 revision：客户端可对 key 或前缀注册 watch，当 key 的写入使 revision 变化时，etcd 推送事件给客户端。watch 支持"从指定 revision 开始监听"（from revision）：客户端可指定一个起始 revision，etcd 会返回该 revision 之后的变更事件（包括可能仍未 compact 的历史事件），从而让客户端能"补课"——读取从上次断开位置开始的所有变更，实现事件重放与断点续传。这在"客户端重启后恢复事件流"、"消费事件不丢"场景很有用。但注意：历史事件保留受 compact 限制，若起始 revision 已被 compact 清理，则无法读取该 revision 之前的事件（需重新全量同步或处理 compact 边界）。MVCC 提供历史版本能力，watch + from revision 提供"从指定点监听/重放"能力。

MVCC 用 revision 保存多版本，watch 基于 revision 推送，from revision 让客户端从指定点监听并重放历史事件。理解"revision 与 compact 的关系"是使用 etcd watch 的关键。

• tickTime 单位时间
• initLimit 初始化同步
• syncLimit 心跳同步

zoo.cfg 是 ZooKeeper 的核心配置文件，几个关键参数：tickTime：基础时间单位（毫秒），用于心跳与超时计算，默认 2000ms，是 ZK 时间计算的基本刻度。initLimit：Follower 初始化时与 Leader 同步（建立连接、同步数据）的最长合理时间，单位为 tickTime 的倍数，默认 10（即 20 秒），用于确认 Follower 能在该时间内完成与 Leader 的初始同步，过大表示初始化慢或网络问题。syncLimit：Follower 与 Leader 之间心跳同步的最长间隔（tickTime 倍数，默认 5），用于检测 Follower 是否存活——若 Follower 在 syncLimit 时间内未与 Leader 通信（心跳超时），Leader 会认为该 Follower 失联，将其从集群中剔除。这些参数共同控制 ZK 的会话超时、节点同步与故障检测。合理设置需结合网络延迟与集群规模：initLimit 要大于初始化同步时间，syncLimit 要大于心跳期望间隔，否则会误判节点失联。

tickTime 是基础单位，initLimit 控制"初始同步容忍时间"，syncLimit 控制"心跳失联判定"。理解它们能正确配置 ZK 集群的故障检测与同步容忍度。

• 协议（Raft vs ZAB）
• 数据模型（KV vs ZNode）
• 生态与场景

etcd 与 ZooKeeper 都是强一致分布式协调系统，但差异明显。协议：etcd 用 Raft（etcd-raft），ZooKeeper 用 ZAB；两者都是"Leader 写 + 多数派提交 + 日志复制"，但 Raft 更易实现、etcd-raft 更模块化，ZAB 以事务（Zxid）为单位。数据模型与 API：etcd 提供简单的 Key-Value + MVCC + watch（revision）+ lease + 事务，API 简洁（gRPC/HTTP）；ZooKeeper 提供 ZNode 层次结构 + watch + 临时/顺序节点，API 更偏文件系统风格。watch 能力：etcd 的 watch 支持前缀/从 revision 监听，ZooKeeper 的 watch 是单节点、一次性。隔离与租约：etcd 有 lease 机制，ZooKeeper 用 session + 临时节点。生态与场景：etcd 是 Kubernetes 控制面元数据标准，云原生场景首选；ZooKeeper 在 Kafka 等传统分布式系统广泛使用（但 Kafka 已用 KRaft 移除 ZK）。总体来说，etcd 更适合云原生 KV + watch + lease 场景，ZooKeeper 更适合传统分布式锁/选主/命名场景。

差异核心是"Raft vs ZAB、KV vs ZNode、云原生 vs 传统"。etcd 简洁（KV + revision + lease）贴合 K8s，ZooKeeper 丰富（层次 + 临时顺序 + watch）适合传统协调。理解差异指导选型。