分布式锁在一组进程之间提供了一种互斥机制。在任何时刻，只有一个进程可以持有锁。分布式锁可以应用于大型分布式系统中实现领导者选举，在任何时间点，持有锁的进程就是系统的领导者。
为了使用ZooKeeper来实现分布式锁服务，我们使用顺序znode来为那些竞争锁的进程强制排序。
实现思路很简单：
首先指定一个作为锁的znode，通常用它来描述被锁定的实体，称为/leader；
然后希望获得锁的客户端创建一些短暂znode，作为锁znode的子节点。
在任何时间点，顺序号最小的客户端将持有锁。
例如，两个客户端差不多同时创建znode，分别为/leader/lock-1 和 /leader/lock-2，那么创建/leader/lock-1的客户端将会持有锁，因为它的znode顺序号最小。
ZooKeeper服务是顺序的仲裁者，因为它负责分配顺序号。
通过删除znode /leader/lock-1即可简单的释放锁；另外，如果客户端进程死亡，对应的短暂znode也会被删除。
接下来，创建/leader/lock-2的客户端将持有锁，因为它的顺序号紧跟前一个。通过创建一个关于znode删除的观察，可以是客户端在获得锁时得到通知。
申请获取所得伪代码：
1.在锁znode下创建一个名为lock-的短暂顺序znode，并且记住它的实际路径名（create操作的返回值）。
2.查询锁znode的子节点并设置一个观察。
3.如果步骤1中所创建的znode在步骤2中所返回的所有子节点中具有最小的顺序号，则获取到锁。退出。
4.等待步骤2中所设置的观察的通知并且转到步骤2.
羊群效应
“羊群效应”就是指大量客户端收到同一事件的通知，但实际只有很少一部分需要处理这一事件。
设想当有成百上千客户端，都在尝试获得锁，每个客户端都会在锁上设置观察，来捕捉节点的变化。每次锁被释放或另一个进程申请获取锁时，观察都会被触发并且每个客户端都会收到一个通知，但只有一个客户端会成功获得锁。这时就会造成大量的峰值流量，给zookeeper服务器造成压力。
为了避免羊群效应，我们需要优化通知事件，将没必要的观察通知去掉，如删除等，只有在前一个顺序号的子节点消失时才需要通知下一个客户端。
ZooKeeper带有一个Java语言编写的生产级别的锁实现，名为writelock，客户端可以很方便的使用它。
ZooKeeper官网关于锁服务的介绍：
http://zookeeper.apache.org/doc/trunk/recipes.html#sc_recipes_Locks