ZooKeeper是专门为分布式系统提供高可用的、高性能的协作服务的，因此为了保证它的写操作，ZooKeeper采用的经典的两阶段提交协议，把写操作当作一个事务来处理。本文主要讨论该协议中的第一阶段，即事务的准备阶段。ZooKeeper的准备阶段主要就是判断该操作在当前环境下能否执行。显然，这一操作只能由当前的Leader来处理，应为Leader握有整个系统最有最全的数据。那么就让我们来研究一下Leader是如何判断各种写操作的可信性吧！

     1.创建节点操作(OpCode.create)

a.根据sessionId判断创建者当前是否还有效

b.判断新节点路径是否在有效(语义)

c.根据创建者的权限来更改爱新节点的权限列表

d.根据新节点的父节点的权限列表来判断创建者是否有权创建该节点

e.如果新节点是sequential，则更新新节点的path

f.验证新节点的path

g.判断节点path是否存在，如果已存在则创建失败

h.如果父节点是ephemeral的话，则它不能有子节点，即不能创建新节点

f.更新父节点的状态信息(子节点数、版本号等)

      2.删除节点操作(OpCode.delete)

a.根据sessionId判断创建者当前是否还有效

b.判断新节点路径是否在有效(语义)

c.判断节点是否存在

d.根据节点的父节点的权限列表来判断操作者是否有权删除该节点

e.判断操作者拥有该节点的信息是否是最新的，否则不能删除该节点

f.如果该节点还有子节点，则不能删除该节点

g.更新父节点的状态信息(子节点数、版本号等)

      3.更新节点值操作(OpCode.setData)

a.根据sessionId判断创建者当前是否还有效

b.判断节点是否存在

c.根据节点的权限列表来判断操作者是否有权修改该节点的值

d.判断操作者拥有该节点的信息是否是最新的，否则不能修改该节点的值

e.更新父节点的状态信息(子节点数、版本号等)

       4.更新节点ACL操作(OpCode.setACL)

a.根据sessionId判断创建者当前是否还有效

b.根据创建者的权限来更改新设置的节点的权限列表

c.判断节点是否存在

d.根据节点的权限列表来判断创建者是否有权更新该节点ACL

e.判断操作者拥有该节点的信息是否是最新的，否则不能更新该节点ACL

f.更新父节点的状态信息(子节点数、版本号等)

      5.创建session操作(OpCode.createSeesion)

      6.关闭session操作(OpCode.closeSeesion)

         在修改已存在节点信息的时候，我们发现验证中会有这样一步：判断操作者拥有该节点的信息是否是最新的，否则不能更新该节点ACL，这是为什么呢？这是因为客户之所以修改节点的信息，是由于它不能“容忍”节点处于该状态，也就要千方百计的修改节点状态，如果该节点已经不再这个状态的话，再修改是没有意义的。