在本节中，我们先从数据模型，节点特性，版本，watcher和ACL五个方面来了解zookeeper系统模型。
数据模型
事务ID
狭义的事务通常指的是数据库事务，，一般包括一系列对数据库有序的读写操作，这些数据库事务所具有的ACID特性，
即原子性，一致性，隔离性，持久性。
在zookeeper中，事务是指能够改变zookeeper服务器状态的操作，我们称之为事物操作或更新操作，一般包括数据节点的
创建与删除，数据节点内容的更新，客户端会话创建与失效等操作。对于每一个事务请求，zookeeper都会为其分配一个
全局的唯一的事务ID，用ZXID来表示，通常是一个64位的数字。每一个ZXID对应一次更新操作，从这些ZXID中可以间接的
识别zookeeper处理这些更新操作请求全局顺序。
节点类型
1.持久节点（PERSISTENT）
所谓持久节点，是指在节点创建后，就一直存在，直到有删除操作来主动清除这个节点——不会因为创建该节点的客户端会话失效而消失。
2.持久顺序节点（PERSISTENT_SEQUENTIAL）
这类节点的基本特性和上面的节点类型是一致的。额外的特性是，在ZK中，每个父节点会为他的第一级子节点维护一份时序，会记录每个子节点创建的先后顺序。基于这个特性，在创建子节点的时候，可以设置这个属性，那么在创建节点过程中，ZK会自动为给定节点名加上一个数字后缀，作为新的节点名。这个数字后缀的范围是整型的最大值。
在创建节点的时候只需要传入节点 “/test_”，这样之后，zookeeper自动会给”test_”后面补充数字。
3.临时节点（EPHEMERAL）
和持久节点不同的是，临时节点的生命周期和客户端会话绑定。也就是说，如果客户端会话失效，那么这个节点就会自动被清除掉。注意，这里提到的是会话失效，而非连接断开。另外，在临时节点下面不能创建子节点。
这里还要注意一件事，就是当你客户端会话失效后，所产生的节点也不是一下子就消失了，也要过一段时间，大概是10秒以内，可以试一下，本机操作生成节点，在服务器端用命令来查看当前的节点数目，你会发现客户端已经stop，但是产生的节点还在。
4.临时顺序节点（EPHEMERAL_SEQUENTIAL）
此节点是属于临时节点，不过带有顺序，客户端会话结束节点就消失。下面是一个利用该特性的分布式锁的案例流程。
状态信息
我们可以针对zookeeper进行节点的创建和内容的更新，每个节点存储内容外还存储一些状态信息。我们可以用get命令来获取状态信息。
Stat类包含了zookeeper上一个数据节点的所有状态信息。
版本——保证分布式数据原子性操作
zookeeper中为数据节点引入了版本的概念，每个数据节点都具有三种类型的版本信息，对数据节点的任何操作更新操作
都会引起版本号的变化。
zookeeper中版本概念和传统软件的版本有很大的区别，它表示的是对数据的数据内容，子节点列表，或是节点ACL信息的修改次数。
在一个数据节点/zk-book被创建完毕之后，节点的version值是0，表示的含义是“当前节点自从创建之后，被更改的次数为0”；如果对该及节点的内容进行更新，那么该节点的version就会变为1.version强调的是变更次数，即使内容没有改变，version次数也会增加。
悲观锁，又称作悲观并发控制，是数据库中一种非常典型且严格的并发控制策略。具有强烈的独占和排他性。能够有效的避免不同事务对同一数据并发更新而造成的数据一致性问题。
乐观锁
我们其实可以把一个乐观锁控制的事务分成三个阶段：读取数据，写入效验，数据写入。
其中写入效验阶段是整个悲观所控制的关键所在。在写入校验阶段，事务会检查数据在读取阶段后是否
有其它事务对数据进行更新过，以确保数据更新的一致性。JDK中乐观锁的实现——CAS。
zookeeper服务器的PreRequestProcessor处理器类中，每一个数据更新请求都会进行如下检查。
Watcher——数据变更通知
在zookeeper中，接口类Watcher用于表示一个标准的事件处理器，其定义了时间通知的相关逻辑，包含keeperState和EventType
两个枚举类，分别代表通知状态和事件类型，同事定义了事件的回调方法：process（watchedEvent event）。
watcher事件
同一个事件类型在不同的通知状态中所代表的含义有所不同
对于AuthFailed这个时间，需要注意的地方是，它的出发条件并不是简简单单因为当前客户端会话没有权限，而是授权失败。
回调方法
process（）方法是watcher接口中的一个回调方法，当zookeeper向哭护短发送wacher事件通知时，客户端就会对应响应的Process方法进行回调
提到wachedEvent，不得不讲WatcherEvent实体。笼统来讲两者表示的是同一个事物，都是对服务端事件的封装。不同的是，wahchedEvent是一个逻辑是件
用于服务端和客户端执行过程中所需的逻辑对象，而watcherEvent实现了序列化接口可以用于网络传出。
服务端在生成watchedEvent事件之后会调用getWrapped方法将自己包装成一个可序列化的watcherEvent事件，以便通过网络传输到客户端。客户端
接受到服务端的这个事件后，会首先将watcherEvent事件还原成一个watchedEvent事件，并传递个Process方法处理。
工作机制
zookeeper的watcher机制，总的来说可以概括为以下三个过程：客户端注册Watcher，服务端处理watcher，客户端回调watcher
客户端注册wacher
服务端处理流程和客户端回调流程可以具体查看此书先关章节。
Watcher特性
一次性：一旦一个watcher被触发，zookeeper就会将其从相应的存储中移除。
客户端串行执行：客户端watcher回调的过程是一个串行同步的过程。这为我们保证了顺序。
轻量：WatchedEvent是最小通知单元，只包含是三部分:通知状态，事件类型，节点路径。
ACL——保障数据的安全
从三个方面来理解ACL机制，分别是：权限模式，授权对象和权限
通常使用“scheme：id：permission”来表示一个有效的ACL信息。
权限模式：Scheme
权限模式用来确定权限验证过程中使用的检验策略。在zookeeper中，开发人员使用最多是一下四种权限模式。
IP
IP模式通过IP地址粒度来进行权限控制，例如配置了“ip：192.168.60.64”，即表示权限控制都是针对这个IP地址的。
同时，IP模式也支持按照网段的方式配置。例如“ip：192.168.0.1/24”表示针对192.168.0.*这个ip段进行权限控制。
Digest
Digest是最常用的权限控制模式，也更符合我们对于权限控制的认识，其以类是与“”username：password”形式
的权限标示来进行权限配置。便于区分不通应用来进行权限控制。
World
world是一种最开放的权限控制模式，从其名字中也可以看出，事实上这种权限控制的方式机会没有任何作用。
数据节点的访问权限对所有用户开放，即所有用户可以不进行任何权限效验的情况下操作zookeeper上的数据。另外，world模式也可以看做是一种特殊的Digest模式，它只是一个权限表示，即“world：anyone”；
Super
Super模式，顾名思义就是超级用户的意思，是一种特殊的Digest模式，在Super模式下，超级用户可以对任意
zookeeper上的数据节点进行任何操作。
授权对象：ID
授权对象指的是权限赋予的用户或一个指定实体，例如IP地址或是 机器等。在不同的权限模式下，授权对象时不同的。
权限：Permission
权限就是指通过权限检查后可以被允许执行的操作。在zookeeper中，所有对数据的操作权限分为以下五大类：
CREATE：数据节点的创建权限，允许授权对象在该数据节点下创建子节点。
DELETE：子节点的删除权限，允许授权对象删除该数据节点的子节点。
READ：数据节点的读取权限，允许授权对象访问该数据节点并读取其内容或子节点列表等。
WRITE：数据节点的权限更新，允许授权对象对该数据节点进行更新操作
ADMIN：数据节点的管理权限，允许授权对象对该数据节点进行ACL相关权限的设置操作。
ACL管理
设置ACL
通过zkCli脚本登陆zookeeper服务器后，可以通过两种方式进行ACL设置。
一种是在数据节点创建的同时进行ACL权限的设置。命令格式如下：
create[-s][-e] path data acl
另一种方式则是使用setACL命令单独对已经存在的数据节点进行ACL设置：
setAcl path acl
具体使用如下
Super模式的用法
如果一个持久数据节点包含了ACL权限控制，而其他创建者客户端已经退出或已经不再使用，
那么这些数据节点该如何清理呢？这个时候，就乣在ACL的super模式下，使用超级管理员权限来进行
权限处理了。要使用超级管理员权限，首先需要在zookeeper服务器上开启super模式。该方法在zook
服务器启动的时候，添加如下系统属性：
其中“foo”代表了一个超级管理员的用户名；密码是可变的，由zookeeper
的系统管理员进行自主配置。此例中使用的是“foo：zk-book”的编码。
完成对zookeeper服务器的SUper模式的开启后，就可以在应用程序中使用了。
从上面的输出结果中，我们可以看出，由于“foo：zk-book”是一个超级管理员账户，因此能够针对一个受限控制的数据及诶单zk-book随意进行操作