系统模型

数据模型

ZooKeeper数据存储的结构与标准的Unix文件系统非常类似，但是并没有引入传统文件系统中目录和文件等概念，而是使用了其特有的数据节点的概念，我们称之为ZNode。Znode是zookeeper中的最小数据单元，每个Znode上都可以保存数据，同时还可以挂载子节点，形成一个树形化命名空间。

如上下图，Znode的节点路径标识方式和Unix文件系统路径非常相似，都是由一系列使用斜杠（/）进行分割的路径表示，最上层的根结点以/代表，并且每个Znode都有一个唯一的路径标识。

⚠️注意：ZooKeeper 主要是用来协调服务的，而不是用来存储业务数据的，所以不要放比较大的数据在 znode 上，ZooKeeper 给出的上限是每个结点的数据大小最大是 1M。

节点特性

节点类型

在ZooKeeper中，Znode节点类型分为持久节点（PERSISTENT）、临时节点（EPHEMERAL）、**顺序节点（SEQUENTIAL）**三大类，通过组合使用，可以生成以下四种组合型节点类型：

• 持久节点：该数据节点被创建后，就会一直存在于ZooKeeper的服务器上，直到有删除操作来主动清除这个节点。
• 持久顺序节点：基本特性与持久节点一致，额外的特性是顺序性，即一个父节点可以为其子节点维护一个创建的先后顺序 ，这个顺序体现在节点名称上，是节点名称后自动添加一个由 10 位数字组成的数字串，从 0 开始计数，上限是整型最大值。
• 临时节点：临时节点的生命周期与客户端的会话绑定在一起，如果客户端会话失效，则这个节点就会自动被清理掉。同时，临时节点不能创建子节点，它只能作为叶子节点使用。
• 临时顺序节点：基本特性与临时节点一致，额外的特性是顺序性。

节点状态

每个数据节点除了存储数据内容之外，还存储了数据节点本身的一些状态信息（如子节点数量、事务id、版本信息等），这些状态信息由Stat这个类来维护。

• czxid：Created ZXID，该数据节点被创建时的事务ID。
• mzxid：Modified ZXID，节点最后一次被更新时的事务ID。
• ctime：Created Time，该节点被创建的时间。
• mtime： Modified Time，该节点最后一次被修改的时间。
• version：节点的版本号。
• cversion：子节点的版本号。
• aversion：节点的 ACL 版本号。
• ephemeralOwner：创建该节点的会话的sessionID ，如果该节点为持久节点，该值为0。
• dataLength：节点数据内容的长度。
• numChildre：该节点的子节点个数，如果为临时节点为0。
• pzxid：该节点子节点列表最后一次被修改时的事务ID，注意是子节点的列表 ，不是内容。

版本

ZooKeeper中为节点引入了版本的概念，每个数据节点都具有三种类型的版本信息，对数据节点的任何更新操作都会引起版本号的变化。

• dataVersion：当前Znode节点数据内容版本号
• cversion：当前Znode节点的子节点版本号。
• aclVersion：当前Znode的ACL变更版本号。

为了解决那些数据更新竞争激烈的场景，ZooKeeper借助版本号机制来实现乐观并发控制。

Watcher

Watcher（事件监听器），是ZooKeeper中的一个很重要的特性。ZooKeeper允许客户端在指定节点上注册一些 Watcher，并且在一些特定事件触发的时候，ZooKeeper服务端会将事件通知到感兴趣的客户端上去，该机制是 ZooKeeper 实现分布式协调服务的重要特性。

从上图中我们可以看到，ZooKeeper的Watcher机制主要包括客户端线程、客户端WatchManager、ZooKeeper服务器三个部分。工作流程如下：

1. 客户端向ZooKeeper服务器注册Watcher对象
2. 客户端将Watcher对象存储在客户端的WatchManager中。
3. 当ZooKeeper服务器触发Watcher事件后，会向客户端发送通知。
4. 客户端从WatchManager中取出对应的Watcher对象来执行回调逻辑。

ACL

ZooKeeper提供了一套完善的ACL（Access Control Lists）权限控制机制来保障数据的安全，类似于Unix/Linux中的UGO权限控制机制。

ACL机制由以下三部分组成，我们通常使用scheme:id:permission来标识一个有效的ACL信息。

• 权限模式（Scheme）
• 授权对象（ID）
• 权限（Permission）

权限模式：Scheme

权限模式是用来确定权限验证过程中使用的校验策略。在ZooKeeper中最常用的就是以下四种权限模式

• IP：IP模式通过IP地址粒度来进行权限控制。
• Digest：Digest是最常用的权限控制模式，其以类似于username:password形式的权限标识来进行权限配置，便于区分不同应用来进行权限控制。当我们配置了权限标识后，为了保证安全，ZooKeeper会分别使用SHA-1算法和BASE64编码进行处理，将其混淆为无法辨识的字符串。
• World：World是最开放的权限控制模式，是一种特殊的Digest模式。在该模式下数据节点的访问权限对所有用户开放，即所有用户都可以在不进行任何数据校验的情况下操作ZooKeeper上的数据。权限标识为world:anyone
• Super：Super模式即超级用户模式，是一种特殊的Digest模式。在该模式下超级用户可以对任意ZooKeeper上的数据节点进行任何操作。

权限对象：ID

授权对象指的是权限赋予的用户或一个指定实体，例如IP地址或是机器等。在不同的权限关系下，授权对象是不同的，对应关系如下图：

• IP：通常是一个IP地址或者一个IP网段，如192.168.0.110或192.168.0.1/24
• Digest：Digest是最常用的权限控制模式，其以类似于username:password形式的权限标识来进行权限配置，便于区分不同应用来进行权限控制。当我们配置了权限标识后，为了保证安全，ZooKeeper会分别使用SHA-1算法和BASE64编码进行处理，将其混淆为无法辨识的字符串。
• World：只有一个ID：anyone
• Super：与Digest模式一致。

权限：Permission

权限就是指那些通过权限检查后可以被允许执行的操作。在ZooKeeper中，所有对数据的操作权限分为以下五大类：

• CREATE：数据节点的创建权限，允许授权对象在该数据节点下创建子节点。
• DELETE：数据节点的删除权限，允许授权对象删除该数据节点的子节点。
• READ：数据节点的读取权限，允许授权对象访问该数据节点并读取其数据内容或子节点列表等。
• WRITE：数据节点的更新权限，允许授权对象对该数据节点进行更新操作。
• ADMIN：数据节点的管理权限，允许授权对象在该数据节点进行ACL相关的设置操作。

Session

Session（会话） 可以看作是ZooKeeper服务器与客户端的之间的一个TCP长连接，通过这个连接，客户端能够通过心跳检测与服务器保持有效的会话，也能够向ZooKeeper服务器发送请求并接受响应，同时还能够通过该连接接收来自服务器的Watcher事件通知。

Session有一个属性叫做：sessionTimeout ，sessionTimeout 代表会话的超时时间。当由于服务器压力太大、网络故障或是客户端主动断开连接等各种原因导致客户端连接断开时，只要在sessionTimeout规定的时间内能够重新连接上集群中任意一台服务器，那么之前创建的会话仍然有效。

另外在每次客户端向服务端发起会话创建请求时，服务端都会为其分配一个SessionID，SessionID用来唯一标识一个会话，因此ZooKeeper必须保证SessionID的全局唯一性。