一、ZooKeeper 数据模型
ZooKeeper 的数据模型是层次模型(Google Chubby 也是这么做的)。层次模型常见于文件 系统。层次模型和 key-value 模型是两种主流的 数据模型。ZooKeeper 使用文件系统模型主要基 于以下两点考虑:
1. 文件系统的树形结构便于表达数据之间的层 次关系。
2. 文件系统的树形结构便于为不同的应用分配 独立的命名空间(namespace)。
ZooKeeper 的层次模型称作 data tree。Data tree 的每个节点叫作 znode。不同于文件系统，每个 节点都可以保存数据。每个节点都有一个版本 (version)。版本从 0 开始计数。
data tree 示例
在右图所示的 data tree 中有两个子树， 一个用于应用1(/app1)和另一个用于 应用2(/app2)。
应用1的子树实现了一个简单的组成员协议:每个客户端进程 p 创建一个 znode p_i 在 /app1 下，只要 /app1/p_i存在就代表进程 p 在正常运行。
data tree 接口
ZooKeeper 对外提供一个用来访问 data tree 的简化文件系统 API:
• 使用UNIX风格的路径名来定位znode,例如/A/X表示znodeA的子节点X。
• znode的数据只支持全量写入和读取，没有像通用文件系统那样支持部分写入和读取。
• datatree的所有API都是wait-free的，正在执行中的API调用不会影响其他API的完成。
• datatree的API都是对文件系统的wait-free操作，不直接提供锁这样的分布式协同机制。但 是 data tree 的 API 非常强大，可以用来实现多种分布式协同机制。
二、znode的分类
一个 znode 可以使持久性的，也可以是临时性的:
1. 持久性的 znode (PERSISTENT): ZooKeeper 宕机，或者 client 宕机，这个 znode 一旦创建就不会丢失。
2. 临时性的 znode (EPHEMERAL): ZooKeeper 宕机了，或者 client 在指定的 timeout 时间内没有连接 server ，都会被认为丢失。
znode 节点也可以是顺序性的。每一个顺序性的 znode 关联一个唯一的单调递增整数。这个单调递增整 数是 znode 名字的后缀。如果上面两种 znode 如果具备顺序性，又有以下两种 znode:
3. 持久顺序性的 znode(PERSISTENT_SEQUENTIAL): znode 除了具备持久性 znode 的特点之外，znode 的 名字具备顺序性。
4. 临时顺序性的 znode(EPHEMERAL_SEQUENTIAL): znode 除了具备临时性 znode 的特点之外，znode 的名字具备顺序性。
ZooKeeper 主要有以上 4 种 znode。
三、Zookeeper总体架构
应用使用 ZooKeeper 客户端库使用 ZooKeeper 服务。 ZooKeeper 客户端负责和 ZooKeeper集群的交互。 ZooKeeper 集群可以有两种模式:standalone模式和 quorum模式。处于standalone 模式的 ZooKeeper 集群还有一个独立运行的 ZooKeeper 节点。处于 quorum模式的 ZooKeeper 集群包换多 个 ZooKeeper 节点。
1. Session
ZooKeeper 客户端库和 ZooKeeper 集群中的节点创建一个 session。客户端可以主动关闭 session。另外如果ZooKeeper 节点没有在 session 关联的 timeout 时间内收到客户端的数据的话， ZooKeeper 节点也会关闭session。另外 ZooKeeper 客户端库如果发现连接的 ZooKeeper 出错，会自动的和其他 ZooKeeper 节点建立连接。
2. Quorum 模式
处于 Quorum模式的 ZooKeeper 集群包含多个 ZooKeeper 节点。 下图的 ZooKeeper 集群有 3 个 节点，其中节点 1 是 leader 节点，节点 2 和节点 3 是 follower 节点。 leader 节点可以处理读写 请求，follower 只可以处理读请求。 follower 在接到写请求时会把写请求转发给leader来处理。
3. 数据一致性
• 可线性化(Linearizable)写入:先到达 leader 的写请求会被先处理，leader 决定写请求的执 行顺序。
• 客户端FIFO顺序:来自给定客户端的请求按照发送顺序执行。
