如果有客户端1、客户端2等N个客户端争抢一个 Zookeeper 分布式锁。大致如下：
1： 大家都是上来直接创建一个锁节点下的一个接一个的临时有序节点
2： 如果自己不是第一个节点，就对自己上一个节点加监听器
3： 只要上一个节点释放锁，自己就排到前面去了，相当于是一个排队机制。
而且用临时顺序节点的另外一个用意就是，如果某个客户端创建临时顺序节点之后，不小心自己宕机了也没关系， Zookeeper 感知到那个客户端宕机，会自动删除对应的临时顺序节点，相当于自动释放锁，或者是自动取消自己的排队。
而且用临时顺序节点的另外一个用意就是，如果某个客户端创建临时顺序节点之后，不小心自己宕机了也没关系， Zookeeper 感知到那个客户端宕机，会自动删除对应的临时顺序节点，相当于自动释放锁，或者是自动取消自己的排队。
几个需要注意的地方如下：
-
死锁问题： 锁不能因为意外就变成死锁，所以要用 ZK 的临时节点，客户端连接失效了，锁就自动释放了。
-
锁等待问题： 锁有排队的需求，所以要 ZK 的顺序节点。
-
锁管理问题： 一个使用使用释放了锁，需要通知其他使用者，所以需要用到监听。
-
监听的羊群效应： 比如有 1000 个锁竞争者，锁释放了，1000 个竞争者就得到了通知，然后判断，最终序号最小的那个拿到了锁。其它 999 个竞争者重新注册监听。这就是羊群效应，出点事，就会惊动整个羊群。应该每个竞争者只监听自己前面的那个节点。比如 2 号释放了锁，那么只有 3 号得到了通知。
)
