ZooKeeper的文件系统、节点操作和事件监听
一、ZooKeeper文件系统的树形结构
ZooKeeper采用类似Unix文件系统的树形结构（也称为ZNode树），所有数据都存储在ZNode节点中，整个结构具有清晰的层级关系，核心特点如下：
-
根节点：整个树形结构的顶层节点，固定为
/，是所有其他节点的父节点，不能被删除，所有操作都围绕根节点或其下子节点展开。 -
层级关系：每个节点（除根节点外）都有且仅有一个父节点，子节点通过“/父节点路径/子节点名称”的格式表示，例如
/app/node1，形成类似目录树的层级结构。 -
节点特性：每个ZNode节点既可以存储少量数据（默认最大1MB，适合存储配置信息、状态标识等轻量数据，不适合存储大量业务数据），也可以作为目录节点，承载子节点，即“文件+目录”一体化的节点设计。
-
路径唯一性：每个节点的路径都是全局唯一的，通过路径可以唯一定位到一个节点，例如
/app/user1和/app/user2是两个不同的唯一节点。
注意：ZooKeeper的树形结构并非用于存储大量数据，核心作用是提供分布式协调服务，通过节点的层级和状态变化，实现服务注册、配置同步、分布式锁等场景。
二、ZooKeeper节点（ZNode）的类型
ZNode节点分为4种核心类型，不同类型的节点具有不同的生命周期和用途，适用于不同的分布式协调场景，具体分类及细节如下：
2.1 持久节点（PERSISTENT）
最基础的节点类型，核心特性：
-
节点创建后，除非主动执行删除操作（delete），否则会一直存在于ZooKeeper中，不受客户端会话关闭的影响。
-
用途：存储长期有效的数据，例如分布式系统的配置信息、服务的基础元数据等，例如
/app/config用于存储应用的全局配置。
2.2 持久顺序节点（PERSISTENT_SEQUENTIAL）
基于持久节点的扩展类型，核心特性：
-
节点创建时，ZooKeeper会自动为节点名称添加一个全局唯一的递增序号（格式为“节点名+序号”，序号由ZooKeeper集群维护，全局自增）。
-
节点生命周期与持久节点一致，除非主动删除，否则一直存在。
-
用途：实现分布式唯一ID生成、分布式队列（按序号顺序消费）等场景，例如
/task/queue-创建后，会自动生成/task/queue-0000000001、/task/queue-0000000002等节点。
2.3 临时节点（EPHEMERAL）
与持久节点相反，核心特性：
-
节点创建后，与创建它的客户端会话绑定，当客户端会话关闭（正常关闭或异常断开）时，该节点会被ZooKeeper自动删除。
-
临时节点不能拥有子节点（即使创建子节点，当客户端会话关闭时，临时节点及其子节点都会被删除）。
-
用途：服务注册与发现（客户端下线后，服务节点自动注销）、分布式锁（客户端释放锁或异常下线后，锁节点自动删除，避免死锁）等场景，例如
/service/server1作为服务节点，客户端下线后自动删除。
2.4 临时顺序节点（EPHEMERAL_SEQUENTIAL）
结合临时节点和顺序节点的特性，核心特性：
-
节点创建时，ZooKeeper会自动为节点名称添加全局唯一的递增序号，同时节点与客户端会话绑定，会话关闭后自动删除。
-
不能拥有子节点，序号全局自增，确保节点名称的唯一性。
-
用途：分布式锁（公平锁，按序号顺序获取锁）、分布式屏障等场景，例如分布式锁场景中，客户端创建临时顺序节点，序号最小的节点获得锁，释放锁或会话断开后，节点删除，下一个序号的节点继续获取锁。
补充说明：所有节点的序号都是64位的长整型数字，从0开始递增，即使节点被删除，序号也不会回滚，确保全局唯一性；临时节点的会话绑定，依赖于客户端与ZooKeeper集群的心跳机制，心跳超时（默认会话超时时间可配置）则视为会话关闭，节点被删除。
三、操作ZNode节点的核心命令（CLI命令行）
ZooKeeper提供CLI（命令行接口）工具，通过简单命令即可完成节点的创建、查询、修改、删除等操作，以下是最常用的核心命令，包含语法、示例及说明：
3.1 连接ZooKeeper集群
语法：zkCli.sh -server 主机IP:端口（Linux/Mac）；zkCli.cmd -server 主机IP:端口（Windows）
示例：zkCli.sh -server localhost:2181（连接本地ZooKeeper服务，默认端口2181）
说明：连接成功后，进入ZooKeeper命令行交互模式，提示符为 [zk: localhost:2181(CONNECTED) 0]。
3.2 创建节点（create）
语法：create [-s] [-e] 节点路径 节点数据
-
-s：可选参数，创建顺序节点（持久顺序/临时顺序）； -
-e：可选参数，创建临时节点（临时/临时顺序）； -
不添加
-s和-e，默认创建持久节点。
示例：
-
创建持久节点：
create /app "app config"（节点路径为/app，数据为"app config"）； -
创建持久顺序节点：
create -s /app/node "node1"（自动生成序号，如/app/node0000000001）； -
创建临时节点：
create -e /service/server1 "192.168.1.100"； -
创建临时顺序节点：
create -s -e /lock/lock- ""（数据为空，仅用序号实现锁机制）。
3.3 查询节点（ls、get）
3.3.1 查看节点列表（ls）
语法：ls 节点路径，查看指定节点下的所有子节点（仅显示子节点名称，不显示数据）。
示例：ls /（查看根节点下的所有子节点）；ls /app（查看/app节点下的子节点）。
3.3.2 查看节点详情（get）
语法：get 节点路径，查看指定节点的内容（数据）、节点属性（版本、类型、创建时间等）。
示例：get /app，输出内容包含：节点数据、版本号（version）、节点类型（ephemeralOwner，0表示持久节点，非0表示临时节点）、创建时间等。
3.4 修改节点数据（set）
语法：set 节点路径 新数据 [版本号]
说明：版本号（version）是可选参数，用于实现乐观锁，只有当节点当前的版本号与指定版本号一致时，才能修改数据，避免并发修改冲突；不指定版本号时，直接覆盖数据。
示例：set /app "new app config" 1（当/app节点的当前版本为1时，修改数据为"new app config"）。
3.5 删除节点（delete、rmr）
3.5.1 删除单个节点（delete）
语法：delete 节点路径 [版本号]
说明：只能删除没有子节点的节点；版本号可选，用于校验节点当前版本，一致时才删除。
示例：delete /app/node1（删除/app/node1节点，需确保该节点无子女）。
3.5.2 递归删除节点（rmr）
语法：rmr 节点路径
说明：递归删除指定节点及其所有子节点，无需手动删除子节点，适合删除有层级的节点。
示例：rmr /app（删除/app节点及其所有子节点）。
3.6 查看节点状态（stat）
语法：stat 节点路径，查看节点的属性信息（不显示节点数据），包括版本号、创建时间、修改时间、节点类型、会话ID等。
示例：stat /app，用于快速查看节点的状态，判断节点是否为临时节点、版本是否匹配等。
补充：所有命令的节点路径必须是绝对路径（以/开头），不能使用相对路径；临时节点删除后，无法通过命令恢复，持久节点删除后，若需恢复需重新创建。
四、ZooKeeper事件监听机制
ZooKeeper的核心特性之一是事件监听（Watcher），客户端可以对指定ZNode节点注册监听，当节点发生指定类型的变化时，ZooKeeper会主动向客户端推送事件通知，客户端根据通知做出相应的业务处理，实现分布式协调的实时性。
4.1 监听机制核心原理
-
注册监听：客户端通过
get、ls等命令（添加-w参数），对指定节点注册监听，监听的是“节点的变化事件”，而非节点本身。 -
事件触发：当节点发生对应变化（如节点创建、删除、数据修改、子节点变化等）时，ZooKeeper集群会检测到变化，并将事件信息（事件类型、节点路径等）推送给注册了该节点监听的客户端。
-
一次性监听：默认情况下，监听是一次性的（One-time Trigger），即事件触发后，该监听就会失效，若需持续监听，客户端需要在事件处理完成后，重新注册监听。
-
异步通知：事件通知是异步推送的，客户端不需要主动轮询节点状态，减少网络开销，提高效率。
4.2 常见监听事件类型
不同的节点操作会触发不同类型的事件，客户端可以根据事件类型判断节点的变化情况，常见事件类型如下：
| 事件类型 | 触发场景 | 对应操作 |
| --- | --- | --- |
| NodeCreated | 监听的节点被创建 | create命令创建该节点 |
| NodeDeleted | 监听的节点被删除 | delete、rmr命令删除该节点 |
| NodeDataChanged | 监听的节点数据被修改 | set命令修改节点数据 |
| NodeChildrenChanged | 监听的节点的子节点发生变化（新增、删除子节点） | create、delete命令操作该节点的子节点 |
| SessionExpired | 客户端会话超时 | 客户端与ZooKeeper集群心跳中断 |
| ConnectionLoss | 客户端与ZooKeeper集群连接断开 | 网络故障、集群宕机等 |
4.3 监听命令示例（CLI方式）
通过CLI命令注册监听，添加-w参数即可，示例如下：
-
监听节点数据变化：
get -w /app，当/app节点数据被修改或节点被删除时，会触发对应事件，命令行输出事件信息； -
监听子节点变化：
ls -w /app，当/app节点新增、删除子节点时，会触发NodeChildrenChanged事件； -
监听节点创建：先执行
get -w /newNode（此时/newNode不存在），再执行create /newNode "test"，会触发NodeCreated事件。
4.4 监听机制的应用场景
监听机制是ZooKeeper实现分布式协调的核心，常见应用场景包括：
-
服务注册与发现：客户端监听服务节点目录（如
/service），当有新服务节点（临时节点）创建或旧服务节点（临时节点）删除时，触发NodeChildrenChanged事件，客户端及时更新服务列表； -
配置同步：客户端监听配置节点（如
/config），当配置节点数据被修改时，触发NodeDataChanged事件，客户端及时拉取新配置，实现全局配置同步； -
分布式锁：客户端监听锁节点（临时顺序节点），当持有锁的节点被删除（释放锁或会话断开）时，触发NodeDeleted事件，其他客户端竞争获取锁；
-
分布式屏障：多个客户端监听同一个屏障节点，当屏障节点被创建或删除时，所有客户端同时触发事件，开始执行后续业务逻辑，实现分布式任务同步。
4.5 监听机制的注意事项
-
一次性监听：默认监听是一次性的，事件触发后监听失效，需手动重新注册，避免遗漏后续变化；
-
事件顺序性：ZooKeeper保证事件推送的顺序与节点变化的顺序一致，客户端可以放心基于事件顺序处理业务；
-
监听范围：监听仅对注册时指定的节点有效，子节点的变化不会触发父节点的监听（除非注册了父节点的子节点监听）；
-
性能影响：过多的监听会增加ZooKeeper集群的压力，建议合理控制监听数量，避免不必要的监听注册。
五、补充总结
ZooKeeper的树形文件系统是其数据存储和协调能力的基础，4种节点类型对应不同的生命周期需求，核心命令可快速操作节点，而事件监听机制则实现了节点变化的实时感知，三者结合，支撑起ZooKeeper的分布式协调核心能力。
实际应用中，需根据业务场景选择合适的节点类型，合理使用监听机制，避免滥用临时节点和监听，确保ZooKeeper集群的稳定性和性能。
