目录
ZooKeeper的节点监听机制,可以保障占有锁的传递有序而且高效
理解了经典的公平可重入锁的原理后,再来看在分布式场景下的公平可重入锁的原理。通过前面的分析,基本可以判定:ZooKeeper 的临时顺序节点,天生就有一副实现分布式锁的胚子。为什么呢?
ZooKeeper分布式锁的原理
ZooKeeper的每一个节点,都是一个天然的顺序发号器。
在每一个节点下面创建临时顺序节点(EPHEMERAL_SEQUENTIAL
)类型,新的子节点后面,会加上一个次序编号,而这个生成的次序编号,是上一个生成的次序编号加一。
例如,有一个用于发号的节点 “/test/lock”
为父亲节点,可以在这个父节点下面创建相同前缀的临时顺序子节点,假定相同的前缀为 “/test/lock/seq-”
。第一个创建的子节点基本上应该为
/test/lock/seq-0000000000,下一个节点则为/test/lock/seq-0000000001,依次类推
![](https://i-blog.csdnimg.cn/blog_migrate/1349f8d9b1e5cb449827bf5e2c230252.png)
ZooKeeper节点的递增有序性,可以确保锁的公平
一个ZooKeeper
分布式锁,首先需要创建一个父节点,尽量是持久节点(
PERSISTENT
类型),然后每个要获得锁的线程,都在这个节点下创建个临时顺序节点。由于ZK
节点,是按照创建的次序,依次递增的。
为了确保公平,可以简单的规定:编号最小的那个节点,表示获得了锁。所以,每个线程在尝试占用锁之前,首先判断自己是排号是不是当前最小,如果是,则获取锁。
ZooKeeper的节点监听机制,可以保障占有锁的传递有序而且高效
每个线程抢占锁之前,先尝试创建自己的 ZNode
。同样,释放锁的时候,就需要删除创建的
Znode
。创建成功后,如果不是排号最小的节点,就处于等待通知的状态。等谁的通知呢?不需要其他人,只需要等前一个 Znode 的通知就可以了。前一个 Znode
删除的时候,会触发
Znode
事件,当前节点能监听到删除事件,就是轮到了自己占有锁的时候。第一个通知第二个、第二个通知第三个,击鼓传花似的依次向后。
ZooKeeper 的节点监听机制,能够非常完美地实现这种击鼓传花似的信息传递。具体的方法是,每一个等通知的Znode
节点,只需要监听(
linsten
)或者监视(
watch
)排号在自己前面那个,而且紧挨在自己前面的那个节点,就能收到其删除事件了。
只要上一个节点被删除了,就进行再一次判断,看看自己是不是序号最小的那个节点,如果是,自己就获得锁。
另外,ZooKeeper
的内部优越的机制,能保证由于网络异常或者其他原因,集群中占用锁的客户端失联时,锁能够被有效释放。一旦占用 Znode
锁的客户端与
ZooKeeper
集群服务器失去联系,这个临时 Znode 也将自动删除。排在它后面的那个节点,也能收到删除事件,从而获得锁。正是由于这个原因,在创建取号节点的时候,尽量创建临时 znode 节点。
ZooKeeper的节点监听机制,能避免羊群效应
ZooKeeper 这种首尾相接,后面监听前面的方式,可以避免羊群效应。所谓羊群效应就是一个节点挂掉,所有节点都去监听,然后做出反应,这样会给服务器带来巨大压力,所以有了临时顺序节点,当一个节点挂掉,只有它后面的那一个节点才做出反应。
分布式锁的抢占过程
接下来我们一起来看看,多客户端获取及释放zk
分布式锁的整个流程及背后的原理。
首先大家看看下面的图,如果现在有两个客户端一起要争抢zk上的一把分布式锁,会是个什么场景?
![](https://i-blog.csdnimg.cn/blog_migrate/aedcc7dbae2b5d338d7266ce306e7e02.png)
如果大家对zk
还不太了解的话,建议先自行百度一下,简单了解点基本概念,比如
zk
有哪些节点类型等等。
参见上图。zk
里有一把锁,这个锁就是
zk
上的一个节点。然后呢,两个客户端都要来获取这个锁,具体是怎么来获取呢?
咱们就假设客户端A
抢先一步,对
zk
发起了加分布式锁的请求,这个加锁请求是用到了
zk
中的一个特殊的概念,叫做“
临时顺序节点
”
。
简单来说,就是直接在"my_lock"
这个锁节点下,创建一个顺序节点,这个顺序节点有
zk
内部自行维护的一个节点序号。
客户端A发起一个加锁请求
比如说,第一个客户端来搞一个顺序节点,zk
内部会给起个名字叫做:
xxx-000001
。然后第二个客户端来搞一个顺序节点,zk
可能会起个名字叫做:
xxx-000002
。大家注意一下,最后一个数字都是依次递增的,从1
开始逐次递增。
zk
会维护这个顺序。
所以这个时候,假如说客户端A
先发起请求,就会搞出来一个顺序节点,大家看下面的图,Curator框架大概会弄成如下的样子:
![](https://i-blog.csdnimg.cn/blog_migrate/3981cc650926ca17443525ff1e668e24.png)
大家看,客户端A
发起一个加锁请求,先会在你要加锁的
node
下搞一个临时顺序节点,这一大坨长长的名字都是Curator
框架自己生成出来的。
然后,那个最后一个数字是"1"
。大家注意一下,因为客户端
A
是第一个发起请求的,所以给他搞出来的顺序节点的序号是"1"
。
接着客户端A
创建完一个顺序节点。还没完,他会查一下"my_lock"这个锁节点下的所有子节点,并且这些子节点是按照序号排序的,这个时候他大概会拿到这么一个集合:
![](https://i-blog.csdnimg.cn/blog_migrate/a71761ea8672c51d18a67e39041e15e1.png)
接着客户端A
会走一个关键性的判断,就是说:唉!兄弟,这个集合里,我创建的那个顺序节点,是不是排在第一个啊?
如果是的话,那我就可以加锁了啊!因为明明我就是第一个来创建顺序节点的人,所以我就是第一个尝试加分布式锁的人啊!
bingo!加锁成功!大家看下面的图,再来直观的感受一下整个过程。
![](https://i-blog.csdnimg.cn/blog_migrate/90ee63926cae8e20ecc5f472caa16076.png)
客户端B过来排队
接着假如说,客户端A
都加完锁了,客户端
B过来想要加锁了,这个时候他会干一样的事儿:先是在"my_lock"这个锁节点下创建一个临时顺序节点,此时名字会变成类似于:
![](https://i-blog.csdnimg.cn/blog_migrate/45749d5fa1b8cb50e7504e8b8909d089.png)
大家看看下面的图:
客户端B
因为是第二个来创建顺序节点的,所以
zk
内部会维护序号为
"2"
。
接着客户端B
会走加锁判断逻辑,查询"my_lock"锁节点下的所有子节点,按序号顺序排列,此时他看到的类似于:
![](https://i-blog.csdnimg.cn/blog_migrate/d25f795bbd70817ee59d3bc1b6836ab5.png)
同时检查自己创建的顺序节点,是不是集合中的第一个?
明显不是啊,此时第一个是客户端A
创建的那个顺序节点,序号为
"01"
的那个。所以加锁失败!
客户端B开启监听客户端A
加锁失败了以后,客户端B
就会通过
ZK
的
API
对他的顺序节点的上一个顺序节点加一个监听器。
zk
天然就可以实现对某个节点的监听。
如果大家还不知道zk
的基本用法,可以百度查阅,非常的简单。客户端B的顺序节点是:
![](https://i-blog.csdnimg.cn/blog_migrate/4e95b9c9652275c6d5b26708653ae738.png)
他的上一个顺序节点,不就是下面这个吗?
即客户端A
创建的那个顺序节点!
所以,客户端B会对下面这个节点加一个监听器,监听这个节点是否被删除等变化!大家看下面的图。
![](https://i-blog.csdnimg.cn/blog_migrate/6d9384d1c0281fe544efb0c9f94110a8.png)
接着,客户端A
加锁之后,可能处理了一些代码逻辑,然后就会释放锁。那么,释放锁是个什么过程呢?
其实很简单,就是把自己在zk里创建的那个顺序节点,也就是将下面这个节点给删除。
![](https://i-blog.csdnimg.cn/blog_migrate/3a520f6e7c84843ec7d5d1f548143ea5.png)
删除了那个节点之后,zk
会负责通知监听这个节点的监听器,也就是客户端
B
之前加的那个监听器,说:兄弟,你监听的那个节点被删除了,有人释放了锁。
![](https://i-blog.csdnimg.cn/blog_migrate/8b151efff5f9e2e1ea77231b67cee780.png)
此时客户端B的监听器感知到了上一个顺序节点被删除,也就是排在他之前的某个客户端释放了锁。
客户端B抢锁成功
此时,就会通知客户端B重新尝试去获取锁,也就是获取"my_lock"节点下的子节点集合,此时为:
集合里此时只有客户端B
创建的唯一的一个顺序节点了!
然后呢,客户端B
判断自己居然是集合中的第一个顺序节点,bingo!可以加锁了!直接完成加锁,运行后续的业务代码即可,运行完了之后再次释放锁。
![](https://i-blog.csdnimg.cn/blog_migrate/d1f7b6bdb02ac3918d19369a55e20eba.png)