ZooKeeper中的写操作细节(一)

r囧r小猫 2022-06-18 01:54 138阅读 0赞

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，这是为什么呢？这是因为客户之所以修改节点的信息，是由于它不能“容忍”节点处于该状态，也就要千方百计的修改节点状态，如果该节点已经不再这个状态的话，再修改是没有意义的。