一文彻底理解一文彻底理解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框架大概会弄成如下的样子：
大家看，客户端A发起一个加锁请求，先会在你要加锁的node下搞一个临时顺序节点，这一大坨长长的名字都是Curator框架自己生成
出来的。
然后，那个最后一个数字是”1″。大家注意一下，因为客户端A是第一个发起请求的，所以给他搞出来的顺序节点的序号是”1″。
接着客户端A创建完一个顺序节点。还没完，他会查一下”my_lock“这个锁节点下的所有子节点，并且这些子节点是按照序号排序的，
这个时候他大概会拿到这么一个集合：
接着客户端A会走一个关键性的判断，就是说：唉！兄弟，这个集合里，我创建的那个顺序节点，是不是排在第一个啊？
如果是的话，那我就可以加锁了啊！因为明明我就是第一个来创建顺序节点的人，所以我就是第一个尝试加分布式锁的人啊！
评论0