1 协调问题
1.1 分布式系统的本质困难
分布式系统的复杂性并不来自业务逻辑，而是来自运行环境的不确定性。只要系统由多个独立进程组成，并通过网络进行通信，就天然失去了单机系统中的许多基本假设。
1.1.1 进程失败是常态
在分布式系统中，任何一个进程都可能在任意时间点失效。导致失效的原因非常多，包括但不限于进程崩溃、机器宕机、重启、Full GC、资源耗尽以及操作系统级别的调度问题。
更复杂的是，从其他节点的视角来看，进程失效与网络隔离在现象上往往无法区分。一个节点可能已经完全不可用，也可能只是暂时无法通信。
1.1.2 网络无法提供可靠时序
网络通信只能提供尽力而为的服务语义。消息可能出现延迟、丢失、重复投递或乱序到达。
这意味着，不同节点对同一组事件的观察顺序可能完全不同。如果系统缺乏统一的顺序判断机制，就无法在并发场景下做出一致决策。
例如，在多个节点同时竞争资源时，如果无法明确“谁先发生”，就无法实现可靠的分布式锁或选举机制。
1.1.3 本地状态无法自动收敛
在分布式系统中，每个节点只能看到自己感知到的局部状态。如果各节点基于本地状态独立做出判断，而缺乏一个全局一致的状态来源，那么随着时间推移，各节点的认知将逐渐偏离。
最终，系统将进入一种不可预测的状态，不同节点对系统整体的理解完全不同，协调行为也会随之失效。
1.2 协调的核心诉求
协调并不是让系统“永远正确”，而是让系统在不可靠环境下仍然可控。
1.2.1 一致的状态视图
在关键决策点上，所有节点必须基于同一份逻辑状态进行判断，例如当前生效的配置版本、Leader 身份以及集群成员列表。
即使系统内部存在短暂的不一致，也必须保证在决策层面使用的是同一视图。
1.2.2 明确的顺序语义
在竞争场景下，必须能够回答“谁先发生”“谁后发生”，否则就无法构建锁、选举、队列等机制。
1.2.3 自动化的故障感知
协调系统必须能够自动感知节点的失效，并及时清理失效节点留下的状态，同时触发必要的重配置流程。
任何依赖人工干预的方案，在规模化系统中都是不可持续的。
1.3 ZooKeeper 的切入点
ZooKeeper 并不试图解决所有分布式问题，而是精准切入协调这一核心领域。
1.3.1 提供强一致的共享状态
ZooKeeper 向外提供一个强一致的共享数据空间，所有客户端在逻辑上看到的是同一份状态视图。
这种一致性是 ZooKeeper 能够支撑分布式协调语义的基础。
1.3.2 提供可组合的协调原语
ZooKeeper 本身只提供极其基础的操作接口，例如节点的创建、删除、读取和监听。
通过组合这些原语，可以构建配置管理、服务发现、分布式锁、选举等高层语义。
1.3.3 限制能力边界以换取可靠性
ZooKeeper 主动限制单节点数据大小、访问模式以及写入吞吐，避免自身成为系统瓶颈。
这种克制式设计，是 ZooKeeper 能够长期稳定运行的关键。
2 系统模型
2.1 集群架构
ZooKeeper 以复制状态机的形式运行在一个节点集群中。
2.1.1 Leader 的职责
Leader 是集群中唯一可以处理写事务的节点。
它负责为写请求分配全局有序的事务 ID，并将事务以广播的方式同步到其他节点，在获得多数派确认后提交事务。
2.1.2 Follower 的职责
Follower 参与事务投票，维护与 Leader 一致的状态副本，同时对客户端提供读服务。
2.1.3 Observer 的存在意义
Observer 不参与投票过程，仅用于扩展集群的读能力。
通过引入 Observer，可以在不影响写性能和一致性保证的前提下，提高系统整体吞吐量。
2.2 多数派原则
ZooKeeper 的所有一致性保证都建立在多数派之上。
2.2.1 多数派的数学基础
任何两个超过半数的集合必然存在交集，这保证了系统状态不会分裂。
2.2.2 为什么必须是奇数节点
奇数节点可以在相同硬件成本下容忍更多节点故障。
2.2.3 多数派对可用性的影响
当存活节点不足半数时，ZooKeeper 会主动拒绝写请求，以保证一致性不被破坏。
2.3 请求处理流程
2.3.1 写请求路径
客户端将写请求发送到任意节点，该节点转发给 Leader，由 Leader 生成事务并广播，最终在多数派确认后提交。
2.3.2 读请求路径
读请求可以由任意节点直接返回本地内存中的数据，不需要与 Leader 交互。
2.3.3 顺序一致性的保证
客户端在同一会话中的操作顺序在集群中严格保持一致。
3 数据模型
3.1 树形命名空间
ZooKeeper 的数据模型是一棵逻辑树，每个节点通过路径唯一标识。
3.1.1 路径即语义
路径不仅用于定位数据，同时也是协调语义的一部分，例如 /lock、/election、/config。
3.1.2 父子关系的工程含义
父节点通常表示逻辑集合，子节点表示集合成员或具体实例。
3.2 ZNode 结构
3.2.1 数据区
ZNode 的数据区用于存储少量结构化信息，ZooKeeper 并不解析其内容。
3.2.2 元数据区
元数据用于描述节点状态，是并发控制与一致性判断的基础。
3.2.3 内存优先设计
ZooKeeper 将数据主要存放在内存中，以保证极低延迟。
3.3 Stat 字段语义
3.3.1 zxid 与全局顺序
zxid 是 ZooKeeper 内部的逻辑时间线，所有事务都按 zxid 全局有序。
3.3.2 版本号的并发控制作用
客户端可以基于版本号进行条件更新，从而避免并发写覆盖。
3.3.3 子节点版本的必要性
对子节点列表的修改同样属于状态变化，必须纳入版本管理。
4 节点类型
4.1 持久节点
4.1.1 生命周期
持久节点独立于客户端会话存在。
4.1.2 使用语义
用于表示长期存在的配置、目录或逻辑结构。
4.1.3 误用风险
将业务数据大量写入持久节点会严重影响 ZooKeeper 性能。
4.2 临时节点
4.2.1 会话绑定
临时节点与 Session 强绑定，Session 失效即删除。
4.2.2 在线语义
临时节点天然表达“活着”的概念。
4.2.3 设计限制
临时节点不能拥有子节点，以避免级联语义复杂化。
4.3 顺序节点
4.3.1 顺序生成机制
顺序号由 Leader 分配，保证在同一父节点下全局递增。
4.3.2 顺序与公平性
顺序节点为锁与选举提供了天然的公平基础。
5 会话模型
5.1 Session 的定义
Session 是客户端在 ZooKeeper 中存在的逻辑凭证。
5.1.1 Session 的建立
Session 在客户端首次连接时由 Leader 分配。
5.1.2 心跳与超时
ZooKeeper 通过心跳判断 Session 是否仍然存活。
5.2 Session 的系统意义
5.2.1 故障感知抽象
ZooKeeper 不检测进程是否崩溃，只检测会话是否消失。
5.2.2 自动清理能力
临时节点的自动删除避免了大量分布式垃圾状态。
6 事件机制
6.1 Watcher 的定位
Watcher 是一种轻量级变化通知机制。
6.1.1 Watcher 的注册方式
Watcher 附加在读操作上注册。
6.1.2 一次性触发语义
Watcher 触发后即失效，必须重新注册。
6.2 Watcher 的一致性边界
6.2.1 事件可能丢失
ZooKeeper 不保证事件完整性。
6.2.2 状态一定可见
客户端始终可以通过重新读取节点获得最终一致状态。
7 一致性协议
7.1 ZAB 的目标
ZAB 用于保证事务顺序一致与故障恢复。
7.1.1 正常广播阶段
Leader 广播事务并等待多数派确认。
7.1.2 崩溃恢复阶段
通过选举最新节点并同步缺失事务恢复一致状态。
7.2 数据不回退保证
7.2.1 zxid 单调性
任何已提交事务都不会被覆盖或回滚。
7.2.2 新 Leader 的数据约束
新 Leader 必须拥有最大 zxid。
8 使用范式
8.1 配置管理
配置存储在持久节点
客户端监听变化并重新加载
8.2 服务发现
实例通过临时节点注册
下线自动清理
8.3 分布式锁
基于临时顺序节点
监听前驱节点避免惊群