本文是zookeeper系列之快速入门中的第二篇，欢迎大家观看与指出不足。
目录
[四、权限控制ACL（Access Control List）](#四、权限控制ACL（Access Control List）)
一、zookeeper的存储结构
zookeeper的存储结构极其类似于文件系统，都是树形结构，如下图所示。
与文件系统不同的是，文件系统分为目录和文件，目录是没有数据的。而zookeeper则全部称为节点（znode），每个节点既能保存数据又有孩子节点。
zookeeper的根节点都是"/"。
每一个节点（znode)的命名空间（类似于java中的包名）都由其路径组成。zookeeper称上面这种结构为分层命名空间（Hierarchical Namespace）。
例如，根节点的命名空间为"/"，第二层左节点的命名空间为"/app1"，右节点的命名空间为"/app2"。
节点的命名空间我们又可以理解为是每个节点的标识符，程序能够根据名称定位到具体是哪个节点。
二、什么是znode
上图中的每个节点在zookeeper中称为znode。在zookeeper推荐在znode中存储的数据不超过1M，这是从性能和效率的角度出发。zookeeper作为协调分布式应用的服务中心，一般是存储状态信息、配置信息和本地数据等等。从设计的初衷上看也不是为了存储大量数据准备的。如果真的要存储大数据，应该把数据存储在别的地方比如数据库上，然后在znode上存储他们的引用。
znode在每次更新数据时，都是全量更新，直接覆盖以前的值，不存在追加或者修改其中某个地方的操作。读取数据也是全部读取。同时，znode的读取和写入都是原子操作。
znode还存储了znode版本信息有三个版本号dataversion（数据版本号）、cversion（子节点版本号）、aclversion（节点所拥有的ACL版本号）。每个版本号其实是一个数字，每次修改对应的版本号就会增加。
比如我们创建一个节点，create /zk "test"后，在linux下用get /zk后返回的信息如下：
test #znode的数据
cZxid = 0x1e #znode的创建事务id
ctime = Tue Sep 29 06:45:54 CST 2020 #znode的创建时间
mZxid = 0x1e #znode的修改事务id
mtime = Tue Sep 29 06:45:54 CST 2020 #修改时间
pZxid = 0x1e #该节点的子节点列表最后一次修改的版本号，添加子节点或删除子节点就会影响子节点列表，但是修改子节点的数据内容则不影响该值，孙子节点的操作也不影响
cversion = 0 #children节点的版本号，每次子节点修改加1，下同
dataVersion = 0 #数据版本号
aclVersion = 0 #ACL(权限控制列表）版本号
ephemeralOwner = 0x0 #如果节点为临时节点，那么它的值为这个节点拥有者的session ID；如果该节点不是ephemeral节点, ephemeralOwner值为0.
dataLength = 4 #数据长度
numChildren = 0 #孩子节点的数量
版本号的作用
Zookeeper里面的版本号和我们理解的版本号不同，它表示的是对数据节点的内容、子节点列表或者ACL信息的修改次数。节点创建时dataversion、aclversion，cversion都为0，每次修改响应内容其对应的版本号加1。
这个版本号的用途就和分布式场景的一个锁概念有关。比如演出售票中的一个座位，显然每个场次中的每个座位都只有一个，不可能卖出2次。如果A下单的时候显示可售，他想买，那么为了保证他可以下单成功，此时别人就不能买。这时候就需要有一种机制来保证同一时刻只能有一个人去修改该座位的库存。这就用到了锁。锁有悲观锁和乐观锁。
-
悲观锁：它会假定所有不同事务的处理一定会出现干扰，数据库中最严格的并发控制策略，如果一个事务A正在对数据处理，那么在整个事务过程中，其他事务都无法对这个数据进行更新操作，直到A事务释放了这个锁。
-
乐观锁：它假定所有不同事务的处理不一定会出现干扰，所以在大部分操作里不许加锁，但是既然是并发就有出现干扰的可能，如何解决冲突就是一个问题。在乐观锁中当你在提交更新请求之前，你要先去检查你读取这个数据之后该数据是否发生了变化，如果有那么你此次的提交就要放弃，如果没有就可以提交。
Zookeeper中的版本号就是乐观锁，你修改节点数据之前会读取这个数据并记录该数据版本号，当你需要更新时会携带这个版本号去提交，如果你此时携带的版本号（就是你上次读取出来的）和当前节点的版本号相同则说明该数据没有被修改过，那么你的提交就会成功，如果提交失败说明该数据在你读取之后和提交之前这段时间内被修改了。
三、znode节点的四种类型
zookeeper有四种节点，临时节点，临时顺序节点，持久节点和持久顺序节点。
3.1 临时节点
当zookeeper的客户端申请zookeeper服务端创建临时节点时，节点的ephemeralOwner为此客户端与服务端的sessionId。当客户端与服务端断开连接时，临时节点也会被删除。
3.2 临时顺序节点
当创建的是临时顺序节点时，会在节点名称后面增加序号，不断递增。
举个例子。比如申请创建的是/zk临时顺序节点，如果此时服务端没有/zk的节点，那么就会创建/zk-1节点。这时第二个请求过来了，也是创建临时顺序节点/zk，那么服务端就会创建/zk-2，依次是/zk-3,/zk-4......不断递增下去，一直到2^32。与临时节点一样的是，当客户端断开链接时，临时顺序节点也会被删除。
3.3 持久节点
顾名思义，就是创建后除非主动删除，否则会一直存在的节点。
3.4 持久顺序节点
当创建的是持久顺序节点时，举个例子。比如申请创建的是/zk临时顺序节点，如果此时服务端没有/zk的节点，那么就会创建/zk-1节点。这是有第二个请求过来了，也是创建临时顺序节点/zk，那么服务端就会创建/zk-2，不断递增下去，一直到2^32。与持久节点一样的是，创建后除非主动删除，否则会一直存在。
四、权限控制ACL（Access Control List）
ZooKeeper的权限控制是基于每个znode节点的，需要对每个节点设置权限。
zookeeper每个节点的权限类型有五种：create、read、delete、write、admin
CREATE：创建子节点的权限
READ：读节点数据的权限包括获取它的子节点列表的权限
DELETE：有删除子节点的权限
WRITE：写节点数据的权限
ADMIN：可以设置节点访问控制列表权限
zookeeper的授权策略（Scheme）有5种：world、auth、digest、ip、x509（有一些博客写了Super即超级管理员模式这个类型，可能是老版本，从3.4开始，官方文档介绍ACL的时候就没看到super了）
world：默认方式，全部都能访问，
auth：认证用户可以使用，(cli中可以通过addauth digest user:pwd 来添加当前上下文中的授权用户)
digest：即用户名:密码这种方式认证，这也是业务系统中最常用的。用 username:password 字符串来产生一个MD5串，然后该串被用来作为ACL ID。认证是通过明文发送username:password 来进行的，当用在ACL时，表达式为username:base64 ，base64是password的SHA1摘要的编码。
ip：使用客户端的主机IP作为ACL ID 。这个ACL表达式的格式为addr/bits ，此时addr中的有效位与客户端addr中的有效位进行比对。
x509 ：uses the client X500 Principal as an ACL ID identity. The ACL expression is the exact X500 Principal name of a client. When using the secure port, clients are automatically authenticated and their auth info for the x509 scheme is set.
ACL 权限控制，使用：scheme:id:perm 来标识，主要涵盖 3 个方面：权限模式（Scheme）：授权的策略 授权对象（ID）:授权的对象 权限类型（Permission）:授予的权限。权限模式和权限类型就是上文所讲，授权对象（ID）很好理解，就是权限赋予的用户或者一个实体，例如：IP 地址或者机器。
五、事件监听watcher
zookeeper可以向节点注册一个watcher，用来监听节点的变化。当节点状态发生变化时，比如说被删除或者修改，那么它就会发送通知到监听这个节点的客户端，客户端因此而做出自己的操作。
每个注册仅使用一次，也就是当发生一次节点改变，通知完客户端之后，如果你需要这个节点下次发生改变时也发送通知到这个客户端，那么就需要再注册一次监听。