Zookeeper详解（三）：Zookeeper中的Znod

数据模型

ZK拥有一个命名空间就像一个精简的文件系统，不同的是它的命名空间中的每个节点拥有它自己或者它下面子节点相关联的数据。ZK中必须使用绝对路径也就是使用“/”开头。

Znode：

ZK目录树中每个节点对应一个Znode。每个Znode维护这一个属性，当前版本、数据版本、建立时间和修改时间等，看下图：

ZK就是使用这些属性来实现特殊功能的。当一个客户端要对某个节点进行修改时，必须提供该数据的版本号，当节点数据发生变化是其版本号就会增加。如下图：

Znode具有如下特性：

• Watches：客户端可以在节点上设置Watches（可以叫做监视器）。当节点状态发生变化时，就会触发监视器对应的操作，当监视器被触发时，ZK服务器会向客户端发送且只发送一个通知

• 数据访问：ZK上存储的数据需要被原子性的操作（要么修改成功要么回到原样），也是就读操作将会读取节点相关所有数据，写操作也会修改节点相关所有数据，，而且每个节点都有自己的ACL。

节点类型：ZK中有几种节点类型，节点类型在节点创建的时候就被确定且不可改变

• 临时节点（EPHEMERAL）：临时创建的，会话结束节点自动被删除，也可以手动删除，临时节点不能拥有子节点

• 临时顺序节点（EPHEMERAL_SEQUENTIAL）：具有临时节点特征，但是它会有序列号，分布式锁中会用到该类型节点

• 持久节点（PERSISTENT）：创建后永久存在，除非主动删除。

• 持久顺序节点（PERSISTENT_SEQUENTIAL）：该节点创建后持久存在，相对于持久节点它会在节点名称后面自动增加一个10位数字的序列号，这个计数对于此节点的父节点是唯一，如果这个序列号大于2^32-1就会溢出。

创建顺序节点

create -s /NODE_NAME DATA    # -e参数为创建临时节点，如果不带参数则创建持久节点

ZK中的时间和版本号：

ZXID：ZK节点状态改变会导致该节点收到一个zxid格式的时间戳，这个时间戳是全局有序的，每次更新都会产生一个新的。如果zxid1的值小于zxid2，那么说明zxid2发生的改变在zxid1之后。zxid是一个唯一的事务ID，具有递增性，一个znode的建立或者更新都会产生一个新的zxid值，具体时间有3个cZxid（节点创建时间）、mZxid（该节点修改时间，与子节点无关）、pZxid（该节点的子节点的最后一次创建或者修改时间，孙子节点无关）

version：对节点的每次操作都会使节点的版本号增加，有三个版本号dataversion（数据版本号）、cversion（子节点版本号）、aclversion（节点所拥有的ACL版本号）

版本号的作用

Zookeeper里面的版本号和我们理解的版本号不同，它表示的是对数据节点的内容、子节点列表或者ACL信息的修改次数。节点创建时dataversion、aclversion，cversion都为0，每次修改响应内容其对应的版本号加1。

这个版本号的用途就和分布式场景的一个锁概念有关。比如演出售票中的一个座位，显然每个场次中的每个座位都只有一个，不可能卖出2次。如果A下单的时候显示可售，他想买，那么为了保证他可以下单成功，此时别人就不能买。这时候就需要有一种机制来保证同一时刻只能有一个人去修改该座位的库存。这就用到了锁。锁有悲观锁和乐观锁。

• 悲观锁：它会假定所有不同事务的处理一定会出现干扰，数据库中最严格的并发控制策略，如果一个事务A正在对数据处理，那么在整个事务过程中，其他事务都无法对这个数据进行更新操作，直到A事务释放了这个锁。

• 乐观锁：它假定所有不同事务的处理不一定会出现干扰，所以在大部分操作里不许加锁，但是既然是并发就有出现干扰的可能，如何解决冲突就是一个问题。在乐观锁中当你在提交更新请求之前，你要先去检查你读取这个数据之后该数据是否发生了变化，如果有那么你此次的提交就要放弃，如果没有就可以提交。

Zookeeper中的版本号就是乐观锁，你修改节点数据之前会读取这个数据并记录该数据版本号，当你需要更新时会携带这个版本号去提交，如果你此时携带的版本号（就是你上次读取出来的）和当前节点的版本号相同则说明该数据没有被修改过，那么你的提交就会成功，如果提交失败说明该数据在你读取之后和提交之前这段时间内被修改了。

这里通过set命令并携带版本号提交更新，版本号相同更新就会成功。

如果你再次更新并使用之前的版本号那么就会失败。