Curator实现zookeeper分布式锁的基本原理

1 比如客户端A和客户端B现在一起来争抢zk的分布式锁，然后客户端a抢先一步对zk发起了加分布式锁的请求—即直接在mylock锁节点下创建了临时顺序节点。

2 然后客户端A会查mylock这个锁节点下的所有子节点，并且这些子节点是按照序号排序的，然后客户端A会走一个关键性的判断–即判断我创建的那个顺序节点是不是第一个。如果是的话就加锁成功。

3接着假如说客户端A都加完了锁，然后客户端B也来加锁，他也是在mylock这个锁节点下创建一个临时顺序节点–即最后的序号是0002结尾的（客户端B因为是第二个来创建顺序节点的，所以zk内部会维护序号为"2"）

4 同时它也会检查自己创建的节点是不是临时顺序节点的第一个，很显然它不是啊，所以这个时候他其实会就加一个监听器

5 监听上一个节点是否被删除等变化。

6 接着客户端A加锁之后，可能处理了一些代码逻辑，之后就释放了锁----即把那个0001节点给删除掉

7 删除节点以后，zk其实会反向通知客户端B的监听器：节点删除了

8 然后客户端会尝试重新加锁

9 会进一步判断自己其实就是临时顺序节点中的第一个节点，就会加锁成功。

总结：

如果有 A，B,C,D等多个节点，来争抢锁，
1. 大家都是上来直接在锁节点下 创建一个接一个的临时顺序节点，
2. 如果自己不是第一个节点，就会对自己的上一个节点加监听器
3. 只有上一个节点释放了锁，自己就排在了前面去。相当于一个排队机制

而且用临时顺序节点的另外一个用意就是，如果某个客户端创建了临时顺序节点以后，不小心宕机了，这个时候zk会自动感知到客户端的宕机，会自动删除对应的临时顺序节点，相当于自动释放锁，取消排队。