Zookeeper使用篇-Zookeeper系统核心模型，百度java面试经验

ctime

ctime代表Create time，与czxid搭配使用，即在创建当前节点的时候，记录创建的时间

mtime

mtime代表Modified time，与mzxid搭配使用，即会记录最后一次节点变更操作的时间

version

version代表当前节点的版本号

cversion

cversion代表当前节点中创建的子节点的版本号

aversion

aversion代表当前节点中ACL权限相关的版本号

ephemeralOwner

ephemeralOwner用来保存创建节点的时候生成的会话sessionId，如果当前节点是持久化节点，这个值一般为0（0x0）

dataLength

dataLength保存了当前节点中存储的数据对应的字节长度

numChildren

numChildren中保存了当前节点中创建的子节点的个数

pzxid

pzxid保存了该节点的子节点列表中最后一次被修改的时候生成的事务ID，需要注意的是这里只有子节点列表变化才会重新生成pzxid，如果某个子节点内容修改等操作并不会生成新的pzxid

节点的版本控制

从stat类的定义中，我们看到，在ZNode中，存在多种事务操作的ID，但是zk是如何保证每次事务操作的正确性和稳定的呢？这个时候我们不禁要考虑分布式场景下一个概念–锁，在分布式系统中，一般事务操作，都要保证排他性，而主流的锁方案分为悲观锁和乐观锁两种。悲观锁具有强烈的独占和排他性，但是整个处理过程中，数据会完全被锁定，其他的事务对该数据将做不了任何操作，哪怕是读取数据的操作，直到事务操作结束释放悲观锁为止。但是在分布式场景下，更多的操作是读取共享的数据，如果使用悲观锁，则会造成大量的数据被锁定，造成性能大幅度下降。因此乐观锁的概念出现，在乐观锁中的绝大多数操作都是不对数据加锁的，而是在更新操作之前，去检查当前事务读取的数据与即将要修改的数据是否一致，从而确定是否在读取完数据到更新数据之前的过程中，有木有别的事务对该数据进行了修改操作。如果发现已经被更新了，则回滚当前事务操作，如果没有修改则执行当前的事务。在JDK中，乐观锁的一个典型实现则是利用CAS理论实现的，而Zookeeper也基于类似的实现方案，在每次事务操作之前，都会在 PrepRequestProcessor处理器中的 setData数据更新操作之前，进行一次版本检查操作，如下:

1. int newVersion = checkAndIncVersion(nodeRecord.stat.getVersion(), setDataRequest.getVersion(), path);

checkAndIncVersion方法如下:

1. privatestaticint checkAndIncVersion(int currentVersion, int expectedVersion, String path)

2. throwsKeeperException.BadVersionException{

3. //判断当前请求的版本不是-1，并且与原来的版本号不同时，则抛出异常，其他情况下则将版本号+1

4. if(expectedVersion != -1&& expectedVersion != currentVersion) {

5. thrownewKeeperException.BadVersionException(pat