标签:ade 删除节点 eve 完成 技术 tab 服务 有一个 效率
标签 : Zookeeper 分布式
加锁, 解锁, 锁超时
- 要保证原子性操作, 加锁和锁超时的操作要一次性执行完毕
- 防止误删锁
- 在误删的基础上, 加一个守护线程, 为锁续命.
Zookeeper的数据存储结构就像是一棵树, 这棵树由节点组成, 这种节点叫做Znode. Znode分为四种类型.
默认的节点类型, 创建节点的客户端和Zookeeper断开连接之后, 该节点依旧存在.
所谓顺序节点, 就是在创建节点的时候, Zookeeper根据节点的创建时间顺序给节点的名称进行编号.
和持久节点相反, 当创建节点的客户端与Zookeeper断开连接之后,临时节点会被删除.
在创建节点时, Zookeeper根据创建的时间顺序给该节点名称进行编号; 当创建节点的客户端与Zookeeper断开连接之后,临时节点会被删除.
上面已经说了Znode的四种类型, 其中最后一种类型 临时顺序节点 是最有利于实现Zookeeper分布式锁的.
- 首先, 在Zookeeper当中创建一个持久节点ParentLock. 当第一个客户端想要获得操作某项数据的锁的时候,需要在该持久节点之下简历一个临时顺序节点
Lock1
.
- 之后,
客户端1
查找ParentLock
下面所有的临时顺序节点并按照大小排序, 判断自己所创建的节点Lock1
是不是顺序最靠前的一个. 如果是第一个节点,则成功获得锁.
- 此时,
客户端2
前来获取该项数据的锁, 则在ParentLock
下再创建一个临时顺序节点Lock2
.
客户端2
查找ParentLock下面所有的临时顺序节点并排序,发现自己的Lock2
节点并不是最靠前的. 于是客户端2
向排序仅仅比它靠前的Lock1
注册Watcher
, 用于监听Lock1
动态. 这意味着Lock2
抢锁失败, 进入等待状态.
- 此时, 如果有一个
客户端3
前来获取锁, 则在ParentLock
下在创建一个临时顺序节点Lock3
.
客户端3
查找ParentLock
下面所有的临时顺序节点并排序, 判断自己所创建的节点Lock3
是不是顺序最靠前的一个, 结果发现Lock3
不是最靠前的. 于是客户端3
同样抢锁失败, 进入了等待状态.
- 这个时候
客户端1
得到了锁,客户端2
监听了客户端1
,客户端3
监听了客户端2
. 这样刚好形成一个等待的队列.
释放锁有两种情况
- 当任务完成时,
客户端1
会显示的调用删除节点Lock1
的指令.
- 获得锁的
客户端1
在执行任务的过程中, 如果崩溃, 则会断开和Zookeeper
服务器的链接, 根据临时节点的特性, 相关联的Lock1
会随之自动删除.
- 由于
客户端2
一直在监听Lock1
的状态,这个时候发现Lock1
注销了,客户端2
会立即接收到通知. 这个时候客户端2
会再次查询ParentLock
下的所有节点, 确认自己所创建的节点是不是最小的节点, 如果是最小的则成功获得锁.
同理可推至
客户端3
分布式锁 | 优点 | 缺点 |
---|---|---|
Zookeeper | 1.有封装好的框架,容易实现. 2.有等待锁的机制( Watcher ),可以提高抢锁的效率,好处多多 |
添加和删除节点的性能比较低 |
Redis | Set 和Del 的性能比较高(毕竟键值数据库,Hash) |
1.实现复杂,需要考虑原子性,误删等情况. 2.没有等待锁的机制,只能通过客户端的自旋来等锁,效率低下. |
标签:ade 删除节点 eve 完成 技术 tab 服务 有一个 效率
原文地址:https://www.cnblogs.com/A-FM/p/11440656.html