zookeeper理论

ZooKeeper 核心理论：会话、节点与监听机制

ZooKeeper 的分布式协调能力，依赖于其底层的会话管理、节点模型和监听机制。这些核心理论是理解 ZooKeeper 工作原理和正确使用的基础，以下从细节展开解析：

ZooKeeper 客户端与集群的交互通过 “会话” 维系，会话是客户端身份标识和操作上下文的载体，其设计直接影响系统的可靠性和一致性。

会话创建与唯一标识
- 客户端连接集群时，ZooKeeper 会分配一个全局唯一的 会话 ID（Session ID），用于标识客户端身份。
- 会话建立过程：客户端通过 TCP 连接到任意节点（Leader 或 Follower），完成握手后生成 Session ID，后续所有操作均关联此 ID。
心跳与超时机制
- 客户端需定期发送 心跳包（默认通过 ping 命令）维持会话活性，心跳间隔由 tickTime 配置（默认 2000ms）。
- 会话超时时间：若超过超时时间（默认最小为 2*tickTime，可通过客户端设置，最大通常为 20*tickTime）未收到心跳，ZooKeeper 会判定客户端失效，自动关闭会话。
- 超时时间的意义：避免客户端故障后，其创建的临时节点（Ephemeral Node）长期残留，影响集群状态。
会话的 FIFO 语义
- 同一会话内的所有请求（如创建节点、修改数据）严格按 先进先出（FIFO） 顺序执行，保证操作的时序一致性。
- 不同会话的请求时序由全局 zxid（事务 ID）保证，zxid 越小，操作发生时间越早。
会话重连与迁移
- 若客户端与当前连接的节点断开（如节点宕机），客户端会自动尝试连接集群中其他存活节点，重连成功后会话继续有效（无需重新创建）。
- 重连过程中，未完成的请求会被重试，确保操作的连续性。

ZooKeeper 的数据以 ZNode 为基本单位，每个 ZNode 不仅存储业务数据，还包含元数据用于一致性控制，其结构设计兼顾了灵活性和可靠性。

节点数据（Data）
- 存储业务相关的轻量信息（如配置项、服务地址、状态标识），默认最大容量为 1MB（设计初衷是存储 “协调信号” 而非大量数据）。
- 示例：/services/user-service 节点存储 192.168.1.100:8080，表示用户服务的地址。
节点元数据（Stat）
元数据记录 ZNode 的生命周期和版本信息，通过 stat /path 命令可查看，核心字段包括：
- czxid：创建节点时的事务 ID（唯一标识创建时间）；
- mzxid：最后一次修改节点的事务 ID；
- ctime/mtime：创建 / 最后修改时间戳；
- dataVersion：数据版本号（每次修改数据时自增，用于乐观锁控制）；
- cversion：子节点版本号（子节点增删时自增）；
- aclVersion：权限控制版本号（ACL 变更时自增）；
- ephemeralOwner：若为临时节点，存储对应的会话 ID；若为持久节点，值为 0。
数据大小限制
- ZNode 数据上限为 1MB，超过会导致创建 / 修改失败。此限制源于 ZooKeeper 的设计定位：作为协调服务，而非分布式存储，过大的数据会增加同步开销，影响集群性能。

ZooKeeper 提供四种节点类型，通过 “持久性” 和 “有序性” 的组合，满足分布式协同的多样化需求。

节点类型	关键字	核心特性	典型应用场景
持久无序节点	`create`	客户端会话结束后不删除，名称与用户指定一致	存储持久配置（如 `/config/db`）
持久有序节点	`create -s`	持久化，名称后追加 10 位自增序号（如 `/task/10000000001`）	分布式队列（按序号排序任务）
临时无序节点	`create -e`	客户端会话失效后自动删除，无序号	服务心跳检测（节点存在 = 服务存活）
临时有序节点	`create -es`	会话失效后删除，名称带有序号	分布式锁（通过序号判断竞争优先级）

临时节点的生命周期：与创建它的会话绑定，会话超时或主动关闭时，节点会被 ZooKeeper 自动删除（即使客户端异常崩溃，也能通过超时机制清理）。临时节点不能有子节点，避免会话失效后子节点成为 “孤儿节点”。
顺序节点的序号规则：序号是 10 位十进制数字，从 0 开始自增，父节点维护独立计数器。若计数器溢出（超过 2^31-1），会从头开始（但实际场景中极少触发，因序号增长速度远低于集群生命周期）。

Watch 机制是 ZooKeeper 实现 “主动通知” 的关键，允许客户端订阅 ZNode 的变化，当事件触发时接收通知，无需轮询，大幅提升协同效率。

注册监听：客户端通过 get /path [watch]、ls /path [watch] 等命令，为目标 ZNode 注册监听（可监听节点数据变更、子节点变化等）。
触发事件：当 ZNode 发生注册的事件（如 create、delete、setData、子节点增删），ZooKeeper 会向客户端发送事件通知。
处理通知：客户端收到通知后，可执行后续逻辑（如重新获取数据、再次注册监听）。

一次性触发：Watch 是 “一次性” 的，触发后自动失效。若需持续监听，需在收到通知后重新注册（避免客户端离线期间的事件丢失）。
事件有序性：客户端先收到事件通知，再看到 ZNode 的变化结果（如先收到 “数据修改” 通知，再读取到新数据），保证时序一致性。
全局触发：无论哪个客户端修改了 ZNode，所有注册了对应 Watch 的客户端都会收到通知（包括修改者自身）。
事件类型：
- NodeCreated：节点被创建时触发；
- NodeDeleted：节点被删除时触发；
- NodeDataChanged：节点数据被修改时触发；
- NodeChildrenChanged：子节点增删时触发（不包括子节点数据修改）。