ZooKeeper 分布式锁机制
本文将基于常用的ZooKeeper分布锁实现框架–Curator，说一下这个框架对ZooKeeper分布式锁的实现。
首先模拟一下两个客户端一起争抢ZK上的一把分布式锁的场景：
ZK里有一把锁，这个锁就是ZK上的一个节点。然后两个客户端都要来获取这个锁。假设客户端A抢先一步，对ZK发起了加分布式锁的请求，这个加锁请求是用到了ZK的“临时顺序节点”。简答来说就是直接在“my_lock”这个锁节点下，创建一个顺序节点，这个节点有ZK内部自行维护的一个节点序号。
例如第一个客户端来搞一个顺序节点，ZK内部会起个名字叫xxx-00001。然后第二个客户端搞一个顺序节点，ZK可能会起个名字叫xxx-00002。规律就是最后一个数字都是依次递增的，从1开始递增，ZK会维护这个顺序。
所以这个时候，假如客户端A先发起请求，就会搞出一个顺序节点，如图所示：
客户端A发起一个加锁请求，先会在你要加锁的node下搞一个临时顺序节点，节点名字由Curator框架自己生成出来，但最后一个数字是“1”，因为客户端是第一个发起请求的。
客户端A常见完一个节点后，它会查一下“my_lock”这个锁节点下的所有子节点，并且这些子节点都是按照序号排序的，这个时候他大概会拿到一个集合：
接着客户端A会走一个关键性的判断：我创建的那个顺序节点，是不是排在第一个？如果是的话，那我就可以加锁了。因为我是第一个创建顺序节点的人，所以我是第一个尝试加分布式锁的人。
客户端A加完锁了，客户端B过来想要加锁，这时它会先在“my_lock”这个锁节点下创建一个临时顺序节点，此时名字大概会是“xxx-00002”
客户端B因为是第二个来创建顺序节点的，所以ZK内部会维护序号为“2”。接着客户端B会走加锁判断逻辑，查询“my_lock”锁节点下的所有子节点，按照顺序排列，类似于：
同时检查自己创建的顺序节点，是不是集合中的第一个？如果不是，那就加锁失败。失败之后，客户端B就会通过ZK的API对他的顺序节点的上一个顺序节点加一个监听器
接着，客户端A加锁之后，逻辑处理完后就会释放锁，释放锁实际就是把ZK里创建的顺序节点“xxx-00001”给删除掉。删除了节点之后，ZK会负责通知监听这个节点的监听器，也就是客户端B的监听器说锁释放了。
此时客户端B的监听器感知到了上一个顺序节点被删除，也就是排在他之前的某个客户单释放了锁，此时客户端B重新尝试去获取锁，也就是获取“my_lock”节点下的子节点集合：
然后客户端B判断自己是否是集合中的第一个顺序节点，如果是，直接完成加锁，运行完业务代码后，再次释放锁。
总结
总结一下多个客户端争抢一个ZK分布式锁的原理：
- 客户端上来直接创建一个锁节点下的一个接一个的临时顺序节点
- 如果自己不是第一个节点，就对自己上一个节点加监听器
- 只要上一个节点释放锁，自己就排到前面去，相当于一个排队机制。
而且用临时加节点的另一个好处就是，如果某个客户端创建临时顺序节点之后，自己宕机了也没关系，ZK感知到那个客户端宕机，会自动删除对应的临时顺序节点，相当于自动释放锁。
最后看一下用Curator框架进行加锁和释放锁的一个过程：
扫一扫
296
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
