zk分布式锁

基于ZooKeeper的分布式锁

Zookeeper 是一个分布式的，开放源码的的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop、HBase的重要组件。是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

Zookeeper是架构通过冗余服务实现高可用性。因此，如果第一次无应答，客户端可以询问另一台Zookeeper主机。Zookeeper节点将它们的数据存储在一个分层的命名空间，非常类似于一个文件系统或一个前缀树结构。客户端可以在节点读写，从而以这种方式拥有一个共享的配置服务。更新是全序的。

zookeeper原理解析：https://www.cnblogs.com/jalja/p/11441174.html

获取锁的简单思路
首先，需要了解的是Zookeeper中临时顺序节点的特性。

第一：节点的生命周期和client会话绑定，即创建节点的客户端会话一旦失效，那么这个节点就会被删除（临时性）

第二：每个父节点都会维护子节点创建的先后顺序，自动为子节点分配一个整型数值，以后缀的形式自动追加到节点名称后，作为这个节点最终的节点名称

基于临时性顺序节点的特性，Zookeeper实现分布式锁的一般思路如下：

client调用create()方法创建“/zk-locks”节点，注意节点的类型是EPHEMRAL_SEQUENTIAL；

client调用getChildren("/zk-locks",watch)来获取所有已经创建的子节点，并同时在这个节点上注册子节点变更通知的watcher；

客户端获取到所有子节点Path后，如果发现自己在步骤1中创建的节点是所有节点中最小的，那么就认为这个客户端获得了锁；

如果在步骤3中，发现不是最小的，那么等待，知道下次节点变更通知的时候，再进行子节点的获取，判断是否获取到了锁；

释放锁也比较容易，就是删除自己创建的那个节点即可。

上述思路中，在集群规模很大的时候，会出现“羊群效应”（Herd Effect）：

在上面的分布式锁的竞争中，有一个细节，就是在getChildren上注册了子节点变更通知Watcher，这有什么问题么？这其实会导致客户端大量重复的运行，而且绝大多数的运行结果都是判断自己并非是序号最小的节点，从而继续等待下一次通知，也就是很多客户端做了很多无用功。更加要命的是，在集群规模很大的情况下，这显然会对Server的性能造成影响，而且一旦同一个时间，多个客户端断开连接，服务器会向其余客户端发送大量的事件通知，这就是所谓的羊群效应！

那其实客户端的核心诉求在于判断自己是否是最小的节点，所以说每个节点的创建者其实不同关心所有节点的变更，真正需要关心的应该是比自己序号小的那个节点是否存在。

思路调整：

client调用create()方法创建“/zk-locks”节点，注意节点类型是EPHEMEREL_SEQUENTIAL;

client调用getChildren("/zk-locks", false)来获取所有已经创建的子节点，这里并不注册任何Watcher；

客户端获取到所有子节点Path后，如果发现自己在步骤1中创建的节点是所有节点中最小的，那么就认为这个客户端获取了锁；

如果在步骤3中，发现不是最小的，那么找到比自己小的那个节点，然后对其调用exist()方法注册事件监听；

之后一旦这个被关注的节点被移除，客户端会收到相应的通知，这个时候客户端需要再次调用getChildren("/zk-locks", false)来确保自己是最小的节点，然后进入步骤3；