讲讲用Zookeeper实现分布式锁的思路

237 阅读2分钟

面试时曾被大佬深深一锤,给我“讲讲用Zookeeper实现分布式锁的思路”?

如果对zookeeper不熟悉的同学,肯定会头脑一震,血压上升,言语结巴,额......额.......额......

面试官:你懂我的意思吧?然后面试基本上就凉凉了。

我们假设A和B同时去竞争一个临界资源,那么为了保证数据一致性或避免由于资源争夺引起的问题,所以需要分布式锁。

zookeeper的分布锁是这样实现的:

1.A需要资源R,那么会向ZK申请一个锁,这个锁建立主锁节点底下(临时顺序节点,节点具有唯一性)。A在加锁之前会判断锁队列里是不是有其他锁,如果自己是第一个那么就加上,此时zk可能会起一个名字叫做xxx-00001.

2.B也想要资源R,也去申请锁,但发现前面有一个xxx-00001了,只能加了个watcher监听第一个锁,同时zk给B起名叫做xxx-00002,等xxx-00001它结束之后再加锁并使用。

3.后来的C D E F一样,后面排队。

然而问题就结束了吗?并没有!

在上述的这个过程,大量进程重复运行分布式锁的竞争过程,并且绝大多数的运行结果都是判断出自己并非是序号最小的节点,从而继续等待下一次通知——这个方式显然不怎么科学。

而分布式锁竞争过程,它的核心逻辑在于:判断自己是否是所有节点中序号最小的。于是,很容易可以联想的到的是,每个节点的创建者只需要关注比自己序号小的那个节点。

所以当zookeeper的集群足够大,上面的处理过程,就有可能会引发羊群效应

解决方案: (1) 进程在竞争上锁时,会发现自己并非所有子节点中最小的,说明自己还没有获取到锁。

(2) 此时客户端需要找到比自己小的那个节点,然后对其调用exist()方法,同时注册事件监听。

(3) 之后当这个被关注的节点被移除了,客户端会收到相应的通知。这个时候客户端需要再次调用getChildren(“locknode”)方法来获取所有已经创建的子节点,确保自己确实是最小的节点了,