一. 数据模型：

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

二. znode：

    zk目录树中每个节点对应一个znode。每个znode维护一些属性，如：当前版本，数据版本，建立时间，修改时间等。

 创建持久有序节点：

(-s为有序，-e为临时， 默认为持久) 。

四.  znode 特性：

  1. 监视(watches):  zk通常以远程服务的方式被访问，如果每次访问znode时，客户端都需要获取节点中的内容，这样代价就很大(如果内容不变,就没有意义)。为了应对这种场景，zk提供了一个基于通知(notifaction)的机制，客户端可以向zk中的node设置watch，当zode节点发生变化(触发监视器)时，向客户端发送一个通知。需要注意的是：监视点是一个单次触发的操作，为接受多个通知，客户端必须在每次通知后设置一个新的监视点。
2. 数据访问：ZK上存储的数据需要被原子性的操作（要么修改成功要么回到原样），也是就读操作将会读取节点相关所有数据，写操作也会修改节点相关所有数据，，而且每个节点都有自己的ACL。

五. znode时间和版本号：

zxid：ZK节点状态改变会导致该节点收到一个zxid格式的时间戳，这个时间戳是全局有序的，每次更新都会产生一个新的。如果zxid1的值小于zxid2，那么说明zxid2发生的改变在zxid1之后。zxid是一个唯一的事务ID，具有递增性，一个znode的建立或者更新都会产生一个新的zxid值。

version：每一个znode都有一个版本号，随着每次数据变化而自增。有两个api操作可以有条件执行： setdata和delete，这两个调用以版本号作为传入参数，只有当传入参数的版本号与服务器上的版本号一致时，才会调用成功。

各字段内容解析：

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

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

  --------------------------------------------------------------------------------------------------------------------------

                         深耕运维行业多年，擅长运维体系建设，方案落地。欢迎交流！

                                                     “V-x”： ywjw996

                                                     《 运维经纬 》