ZooKeeper分布式锁详解

ZooKeeper分布式锁详解

分布式锁机制

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

简单来说,就是在My_lock这个锁节点上创建了一个顺序节点,在zk内部自行维护的一个节点顺序号

举个栗子:

​ 第一个客户端来搞一个顺序节点,zk内部会给起个名字叫做:xxx-000001.然后第二个客户端来搞一个顺序节点,zk可能会起个名字叫做:xxx-000002,最后一个数字都是一次递增的,从1开始递增,zk会维护这个顺序

​ 接着,A创建完一个顺序节点,会查看my_lock这个锁节点下的所有子节点,并且这些子节点是按照序号排序的,会得到所有子节点序号的集合,然后进行判断,判断是否是排在第一个,如果是的话,就可以加锁了

​ A加完锁后,B过来想要加锁,B会干一样的事,现在My_lock下创建一个临时顺序节点,名称类似于asdfad-lock-000002

因为是第二个来创建顺序节点的,所以zk内部会维护序号2,接着判断是不是节点集合中的第一个,判断完得出不是,很遗憾加锁失败,加锁失败后,B不甘心,于是对上一个顺序节点加了一个监听器,zk天然就可以实现对某个节点进行监听(watch机制),也就是监听A创建的那个顺序节点,随时等待A被删除,然后上位加锁

​ 之后,A加锁后,处理了一些逻辑后就释放锁了,也就是把自己创建的那个临时节点删除掉,B被zk通知重新尝试去获取锁,也就是获取my_lock节点下的子节点集合,此时只有B创建的唯一顺序节点,上位加锁!

有了多个CDF来争抢锁的情况

​ 都是上来先直接创建一个锁节点下的一个接一个临时节点,如果自己不是第一个节点,那么就对上一个节点进行监听,等待zk通知上位,此时相当于一个派对机制

为什么要使用临时顺序节点

​ 如果某一个客户端创建临时顺序节点后,不小心宕机了,那么zk也可以感知到,会自动删除对应的临时顺序节点,相当于自动释放锁,或者自动取消自己的派对

// 定义锁节点名称
InterProcessMutex lock = InterProcessMutex(client, "/locks/my_lock");
// 加锁
lock.acquire();
// 业务逻辑代码
pass
// 释放锁
lock.release();