zookeeper实现分布式锁及 如何避免羊群效应

问题导读：
1.zookeeper如何实现分布式锁？
2.什么是羊群效应？
3.zookeeper如何释放锁？

在zookeeper应用场景有关于分布式集群配置文件同步问题的描述，设想一下如果有100台机器同时对同一台机器上某个文件进行修改，如何才能保证文本不会被写乱，这就是最简单的分布式锁，本文介绍利用zk实现分布式锁。下面是写锁的实现步骤

分布式写锁
create一个PERSISTENT类型的znode，/Locks/write_lock

1.客户端创建SEQUENCE|EPHEMERAL类型的znode，名字是lockid开头，创建的znode是/Locks/write_lock/lockid0000000001
2.调用getChildren()不要设置Watcher获取/Locks/write_lock下的znode列表
3.判断自己步骤2创建znode是不是znode列表中最小的一个，如果是就代表获得了锁，如果不是往下走
4.调用exists()判断步骤2自己创建的节点编号小1的znode节点(也就是获取的znode节点列表中最小的znode)，并且设置Watcher，如果exists()返回false，执行步骤3
5.果exists()返回true,那么等待zk通知，从而在回掉函数里返回执行步骤3

如果首先介绍一下，Zookeeper中有一种节点叫做顺序节点，故名思议，假如我们在/lock/目录下创建节3个点，ZooKeeper集群会按照提起创建的顺序来创建节点，节点分别为/lock/0000000001、/lock/0000000002、/lock/0000000003。
ZooKeeper中还有一种名为临时节点的节点，临时节点由某个客户端创建，当客户端与ZooKeeper集群断开连接，则开节点自动被删除。
利用上面这两个特性，我们来看下获取实现分布式锁的基本逻辑：
客户端调用create()方法创建名为“locknode/guid-lock-”的节点，需要注意的是，这里节点的创建类型需要设置为EPHEMERAL_SEQUENTIAL。(临时有序节点)
客户端调用getChildren(“locknode”)方法来获取所有已经创建的子节点，同时在这个节点上注册上子节点变更通知的Watcher。
客户端获取到所有子节点path之后，如果发现自己在步骤1中创建的节点是所有节点中序号最小的，那么就认为这个客户端获得了锁。
如果在步骤3中发现自己并非是所有子节点中最小的，说明自己还没有获取到锁，就开始等待，直到下次子节点变更通知的时候，再进行子节点的获取，判断是否获取锁。
释放锁的过程相对比较简单，就是删除自己创建的那个子节点即可。exists()返回true,那么等待zk通知，从而在回掉函数里返回执行步骤3

释放锁就是删除znode节点或者断开连接就行

*注意：上面步骤2中getChildren()不设置Watcher的原因是，防止羊群效应，如果getChildren()设置了Watcher，那么集群一抖动都会收到通知。在整个分布式锁的竞争过程中，大量重复运行，并且绝大多数的运行结果都是判断出自己并非是序号最小的节点，从而继续等待下一次通知—，这个显然看起来不怎么科学。客户端无端的接受到过多的和自己不相关的事件通知，这如果在集群规模大的时候，会对Server造成很大的性能影响，并且如果一旦同一时间有多个节点的客户端断开连接，这个时候，服务器就会像其余客户端发送大量的事件通知——这就是所谓的羊群效应。
下面是代码实现

Watcher 触发条件：

客户端是通过 getData、 getChildren 和 exist 三个接口来向 ZooKeeper 服务器注册 Watcher，且需要多次注册

    增、删、改 ( 重复修改也会触发，因为他只告诉你变更了，不告诉你变更多少，需要 客户端 自己去拿）