Zookeeper server提供了分层次的命名空间，其类似于标准的文件系统，结构如下：
Zookeeper命名空间下的每个节点都叫做Znode，如上面的/app1，/app2, /app1/p_1, /app1/p_2, /app1/p_3…都是Znode节点，我们把Znode节点叫做Zookeeper的数据节点。每个节点都可以关联节点，最下层的节点是子节点，非下层节点为父节点。每个Znode节点都会维护着一个stat structure。
stat structure中包括如下数据：version numbers for data changes, ACL changes, and timestamps。
数据节点类型
| 节点类型 | 详解 |
|---|
| PERSISTENT | 持久化目录节点，客户端与zookeeper断开连接后，该节点还存在 |
| PERSISTENT_SEQUENTIAL | 持久化顺序编号目录节点。客户端与zookeeper断开连接后，该节点还存在，只是Zookeeper给该节点名称进行顺序编号 |
| EPHEMERAL | 临时目录节点。客户端与zookeeper断开连接后，该节点被删除 |
| EPHEMERAL_SEQUENTIAL | 临时顺序编号目录节点。客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号 |
Watches
Zookeeper api中对Znode节点的读操作相关的API都有一个选项设置watch，具体api有getData(), getChildren(), exist(). Zookeeper watches主要有如下3个特点
| 特点 | 基本介绍 |
|---|
| 只触发一次 | 每次我们通过上面api注册watch之后，一旦znode检测path上的数据有改变，就会向客户端推送一个watch事件。但是这个watch事件只会推送一次，如果需要多次推送，需要在每次收到watch事件之后通过相关api再进行一次注册 |
| 发送给客户端 | 一个事件会发送给客户端，但可能在操作成功的返回值到达发起变动的客户端之前，这个事件还没有送达watch的客户端。Watch是异步发送的。但ZooKeeper保证了一个顺序：一个客户端在收到watch事件之前，一定不会看到它设置过watch的值的变动 |
| 被设置了watch数据 | 主要是指zookeeper维护了两个集合的watches，一个是数据watches，另一个是子节点watches。getData()和exists()针对数据watches，getChildren()针对子节点watches |
Znode的API
| API | 详解 |
|---|
| create | 为指定path创建节点 |
| delete | 删除一个节点 |
| exists | 测试指定path下是否存在该节点 |
| get data | 从节点获取数据 |
| set data | 写入数据到指定path的节点 |
| get children | 获取节点下的所有子节点 |
