一文彻底理解ZooKeeper分布式锁的实现原理

太过爱你忘了你带给我的痛 2024-04-19 12:04 51阅读 0赞

**一、写在前面**

本文基于比较常用的**Curator**这个开源框架，聊一下这个框架对ZooKeeper（以下简称zk）分布式锁的实现。

一般除了大公司是自行封装分布式锁框架之外，建议大家用这些开源框架封装好的分布式锁实现，这是一个比较快捷省事儿的方式。

**二、ZooKeeper分布式锁机制**

接下来我们一起来看看，多客户端获取及释放zk分布式锁的整个流程及背后的原理。

首先大家看看下面的图，如果现在有两个客户端一起要争抢zk上的一把分布式锁，会是个什么场景？

![640?wx\_fmt=png][640_wx_fmt_png]

如果大家对zk还不太了解，建议先百度一下，快速了解一些基本概念，比如zk有哪些节点类型等等。

参见上图。zk里有一把锁，这个锁就是zk上的一个节点。然后呢，两个客户端都要来获取这个锁，具体是怎么来获取呢？

咱们就假设客户端A抢先一步，对zk发起了加分布式锁的请求，这个加锁请求是用到了zk中的一个特殊的概念，叫做**“临时顺序节点”。**

简单来说，就是直接在"my\_lock"这个锁节点下，创建一个顺序节点，这个顺序节点有zk内部自行维护的一个节点序号。

比如说，第一个客户端来搞一个顺序节点，zk内部会给起个名字叫做：xxx-000001。然后第二个客户端来搞一个顺序节点，zk可能会起个名字叫做：xxx-000002。大家注意一下，**最后一个数字都是依次递增的**，从1开始逐次递增。zk会维护这个顺序。

所以这个时候，假如说客户端A先发起请求，就会搞出来一个顺序节点，大家看下面的图，Curator框架大概会弄成如下的样子：

![640?wx\_fmt=png][640_wx_fmt_png 1]

大家看，客户端A发起一个加锁请求，先会在你要加锁的node下搞一个临时顺序节点，这一大坨长长的名字都是Curator框架自己生成出来的。

然后，那个最后一个数字是"1"。大家注意一下，因为客户端A是第一个发起请求的，所以给他搞出来的顺序节点的序号是"1"。

接着客户端A创建完一个顺序节点。还没完，他会查一下"**my\_lock**"这个锁节点下的所有子节点，并且这些子节点是按照序号排序的，这个时候他大概会拿到这么一个集合：

![640?wx\_fmt=png][640_wx_fmt_png 2]

接着客户端A会走一个关键性的判断，就是说：唉！兄弟，这个集合里，我创建的那个顺序节点，是不是排在第一个啊？

如果是的话，那我就可以加锁了啊！因为明明我就是第一个来创建顺序节点的人，所以我就是第一个尝试加分布式锁的人啊！

bingo！**加锁成功**！大家看下面的图，再来直观的感受一下整个过程。

![640?wx\_fmt=png][640_wx_fmt_png 3]

接着假如说，客户端A都加完锁了，客户端B过来想要加锁了，这个时候他会干一样的事儿：先是在"**my\_lock**"这个锁节点下创建一个**临时顺序节点**，此时名字会变成类似于：

![640?wx\_fmt=png][640_wx_fmt_png 4]

**大家看看下面的图：**

![640?wx\_fmt=png][640_wx_fmt_png 5]

客户端B因为是第二个来创建顺序节点的，所以zk内部会维护序号为"2"。

接着客户端B会走加锁判断逻辑，查询"**my\_lock**"锁节点下的所有子节点，按序号顺序排列，此时他看到的类似于：

![640?wx\_fmt=png][640_wx_fmt_png 6]

同时检查自己创建的顺序节点，是不是集合中的第一个？

明显不是啊，此时第一个是客户端A创建的那个顺序节点，序号为"01"的那个。**所以加锁失败**！

加锁失败以后，客户端B就会通过ZK的API，**对他的****上一个顺序节点加一个监听器。**zk天然就可以实现对某个节点的监听。

我们举例说明，客户端B的顺序节点是：

![640?wx\_fmt=png][640_wx_fmt_png 7]

他的上一个顺序节点，不就是下面这个吗？

![640?wx\_fmt=png][640_wx_fmt_png 8]

也就是客户端A创建的那个顺序节点！

所以，客户端B会对：

![640?wx\_fmt=png][640_wx_fmt_png 8]

这个节点加一个监听器，监听这个节点是否被删除等变化！

说了那么多，老规矩，给大家来一张图，直观的感受一下：

![640?wx\_fmt=png][640_wx_fmt_png 9]

接着，客户端A加锁之后，可能处理了一些代码逻辑，然后就会释放锁。那么，释放锁是个什么过程呢？

其实很简单，就是把自己在zk里创建的那个顺序节点，也就是：

![640?wx\_fmt=png][640_wx_fmt_png 8]

这个节点给删除。

删除了那个节点之后，zk会负责通知监听这个节点的监听器，也就是客户端B之前加的那个监听器，说：兄弟，你监听的那个节点被删除了，有人释放了锁。

我们一起来看看下面的图，体会一下这个过程：

![640?wx\_fmt=png][640_wx_fmt_png 10]

此时客户端B的监听器感知到了上一个顺序节点被删除，也就是排在他之前的某个客户端释放了锁。

此时，就会通知客户端B重新尝试去获取锁，也就是获取"**my\_lock**"节点下的子节点集合，此时为：

![640?wx\_fmt=png][640_wx_fmt_png 11]

集合里此时只有客户端B创建的唯一的一个顺序节点了！

然后呢，客户端B一判断，**发现自己居然是集合中的第一个顺序节点**，bingo！可以加锁了！**直接完成加锁**，运行后续的业务代码即可，运行完了之后再次释放锁。

最后，再给大家来一张图，大伙儿顺着图仔细的捋一捋这整个过程：

![640?wx\_fmt=png][640_wx_fmt_png 12]

**三、总结**

其实如果有客户端C、客户端D等N个客户端争抢一个zk分布式锁，原理都是类似的。

*  大家都是上来直接创建一个锁节点下的一个接一个的临时顺序节点
 *  如果自己不是第一个节点，就对自己上一个节点加监听器
 *  只要上一个节点释放锁，自己就排到前面去了，相当于是一个排队机制。

而且用临时顺序节点的另外一个用意就是，如果某个客户端创建临时顺序节点之后，不小心自己宕机了也没关系，zk感知到那个客户端宕机，会自动删除对应的临时顺序节点，相当于自动释放锁，或者是自动取消自己的排队。

最后，咱们来看下用Curator框架进行加锁和释放锁的一个过程：

![640?wx\_fmt=png][640_wx_fmt_png 13]

其实用开源框架就是这点好，方便。这个Curator框架的zk分布式锁的加锁和释放锁的实现原理，其实就是上面我们说的那样子。

但是如果你要手动实现一套那个代码的话。还是有点麻烦的，要考虑到各种细节，异常处理等等。所以大家如果考虑用zk分布式锁，可以参考下本文的思路。

--------------------

**新福利:**

**从9月11日开始至10月15日截止，一共五周时间，每周二我会从公众号底部留言互动+分享+再看综合最多的读者中抽取一名读者，免费包邮送实体新书《HBase原理与实践》，留言互动起来吧~**

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg]

猜你喜欢

1、

2、

3、

4、

![640?wx\_fmt=png][640_wx_fmt_png 14]

**扫码关注我们**

过往记忆大数据

个人微信号：fangzhen0219

拉你进技术交流群

[640_wx_fmt_png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/14d2c0a3f59e4ae69c432f32a6f31c89.png
[640_wx_fmt_png 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/9b3cc48746084e48ad66a484fa7ebda4.png
[640_wx_fmt_png 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/f2dd821a86824f89bc18633e55529686.png
[640_wx_fmt_png 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/c6d6c5259b5c4c01b658a2b3dc1dccf5.png
[640_wx_fmt_png 4]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/67762779ba30499cb76ba3c382b9e37a.png
[640_wx_fmt_png 5]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/6570a517c6ca4df4b92a6711bd59c19a.png
[640_wx_fmt_png 6]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/473b0e92fc5e4664839aa9ffde58c0fa.png
[640_wx_fmt_png 7]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/cbbdcfe36f0b4f31a571ad59dfe1a0a2.png
[640_wx_fmt_png 8]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/40e9b698d3f646d6b7458cbe8548c8bd.png
[640_wx_fmt_png 9]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/b66d92289eb545b398449cf40b7cf969.png
[640_wx_fmt_png 10]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/5ab5a5d2eb2e4aaca9d838e86a133a56.png
[640_wx_fmt_png 11]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/6eec51fa61fa43d4ad7cddfb0d316477.png
[640_wx_fmt_png 12]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/0cb519d5969547e2a26a7e07c4982a4e.png
[640_wx_fmt_png 13]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/ba70cf0be7744712ba93c8f65105c955.png
[640_wx_fmt_jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/b4448d8aabab41e79a23eb84bc1f6713.png
[640_wx_fmt_png 14]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/1c005f77559d474ebe9e01f5a4348abc.png