ZooKeeper锁服务

Mrfei

　　分布式锁在一组进程之间提供了一种互斥机制。在任何时刻，只有一个进程可以持有锁。分布式锁可以应用于大型分布式系统中实现领导者选举，在任何时间点，持有锁的进程就是系统的领导者。
　　为了使用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 将按照如下方式实现加锁的操作：
　　1 ） ZooKeeper 调用 create （）方法来创建一个路径格式为“ _locknode_/lock- ”的节点，此节点类型为 sequence （连续）和 ephemeral （临时）。也就是说，创建的节点为临时节点，并且所有的节点连续编号，即“ lock-i ”的格式。
　　2 ）在创建的锁节点上调用 getChildren （）方法，来获取锁目录下的最小编号节点，并且不设置 watch 。
　　3 ）步骤 2 中获取的节点恰好是步骤 1 中客户端创建的节点，那么此客户端获得此种类型的锁，然后退出操作。
　　4 ）客户端在锁目录上调用 exists （）方法，并且设置 watch 来监视锁目录下比自己小一个的连续临时节点的状态。
　　5 ）如果监视节点状态发生变化，则跳转到第 2 步，继续进行后续的操作，直到退出锁竞争。
　　解锁：
　　ZooKeeper 解锁操作非常简单，客户端只需要将加锁操作步骤 1 中创建的临时节点删除即可。
　　

　　羊群效应
　　“羊群效应”就是指大量客户端收到同一事件的通知，但实际只有很少一部分需要处理这一事件。
　　设想当有成百上千客户端，都在尝试获得锁，每个客户端都会在锁上设置观察，来捕捉节点的变化。每次锁被释放或另一个进程申请获取锁时，观察都会被触发并且每个客户端都会收到一个通知，但只有一个客户端会成功获得锁。这时就会造成大量的峰值流量，给zookeeper服务器造成压力。
　　为了避免羊群效应，我们需要优化通知事件，将没必要的观察通知去掉，如删除等，只有在前一个顺序号的子节点消失时才需要通知下一个客户端。
　　

　　ZooKeeper带有一个Java语言编写的生产级别的锁实现，名为writelock，客户端可以很方便的使用它。
　　ZooKeeper官网关于锁服务的介绍：
　　http://zookeeper.apache.org/doc/trunk/recipes.html#sc_recipes_Locks