面试时曾被大佬深深一锤，给我“讲讲用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”)方法来获取所有已经创建的子节点，确保自己确实是最小的节点了，