年底裸辞准备面试，我用7张图画了ZK分布式锁！

一、写在前面

之前写过一篇文章：《都2022年了，出去面试连分布式锁的源码你都不会画？》，给大家说了一下Redisson这个开源框架是如何实现Redis分布式锁原理的，这篇文章再给大家聊一下ZooKeeper实现分布式锁的原理。

同理，我是直接基于比较常用的Curator这个开源框架，聊一下这个框架对ZooKeeper（以下简称zk）分布式锁的实现。

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

---

二、ZooKeeper分布式锁机制

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

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

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

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

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

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

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

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