图解curator如何实现zookeeper分布式锁_curator 锁

curator提供了四种分布式锁，都实现自接口InterProcessLock；

JAVA-doc：https://curator.apache.org/apidocs/org/apache/curator/framework/recipes/locks/package-summary.html

1> InterProcessMutex

• 可重入排它锁，每成功加锁一次，就要解锁一次。

2> InterProcessSemaphoreMutex

• 不可重入排他锁

3> InterProcessReadWriteLock

• 可重入读写锁，读共享，写互斥；
• 一个拥有写锁的线程可重入读锁，但是读锁却不能进入写锁。
• 这意味着写锁可以降级成读锁， 比如请求写锁 —>请求读锁—>释放读锁 —->释放写锁。

4> InterProcessMultiLock

• 联锁， 将多个锁作为单个实体管理的容器；
• 当调用acquire()， 所有的锁都会被acquire()，如果请求失败，所有的锁都会被release。 同样调用release时所有的锁都被release(失败被忽略)。

下面以可重入排他锁InterProcessMutex为例，展开讨论；

三、Zookeeper分布式锁概述

1、Zookeeper分布式锁实现思路

Zookeeper实现排他锁的设计思路如下：

• zk用/lock节点作为分布式锁，当不同的客户端到zk竞争这把锁的时候，zk会按顺序给不同的客户端创建一个临时子节点，挂在作为分布式锁的节点下面。

• 假设第一个来到的客户端为A，第二个来到的是B，分布式锁节点下挂的第一个节点就是A（/lock/_c_A），B（/lock/_c_B）紧跟着A，且B会监听着A的生命状态；

  • 这里B会先获取到/lock路径下所有的节点，发现自己的锁节点（/lock/_c_B）不在第一位，进而监听自己前一位的锁节点（/lock/_c_A）。

• 当A释放锁后A节点会被删除；B监听到A被删除，B可以尝试获得分布式锁了。

  • 具体体现为：客户端B获取/lock下的所有子节点，并进行排序，判断排在最前面的是否为自己，如果自己的锁节点在第一位，代表取锁成功。
  • 如果还有C节点、D节点，他们都只会监听他们前一个节点，即：C监听B、D监听C。

2、Zookeeper分布式锁解决的问题

1> 锁无法释放？

• 使用Zookeeper可以有效的解决锁无法释放的问题，因为在创建锁的时候，客户端会在ZK中创建一个临时节点，一旦客户端获取到锁之后突然挂掉（Session连接断开），那么这个临时节点就会自动删除掉。其他客户端就可以再次获得锁。

2> 互斥阻塞锁？

• 使用Zookeeper可以实现阻塞的锁，客户端可以通过在ZK中创建顺序节点，并且在节点上绑定监听器，一旦节点有变化，Zookeeper会通知客户端，客户端可以检查自己创建的节点是不是当前所有节点中序号最小的，如果是，那么自己就获取到锁，便可以执行业务逻辑了。

3> 不可重入？

• 使用Zookeeper也可以有效的解决不可重入的问题，客户端在创建节点的时候，把当前客户端的主机信息和线程信息直接写入到节点中，下次想要获取锁的时候和当前最小的节点中的数据比对一下就可以了。如果和自己的信息一样，那么自己直接获取到锁，如果不一样就再创建一个临时的顺序节点，参与排队。</