简介
本文介绍用Zookeeper来实现分布式锁的方法和原理。
节点类型
让我们来回顾一下Zookeeper节点的概念：
Zookeeper的数据存储结构就像一棵树，这棵树由节点组成，这种节点叫做Znode。Znode分为四种类型：
1.持久节点 （PERSISTENT）
默认的节点类型。创建节点的客户端与Zookeeper断开连接后，该节点依旧存在 。
2.持久顺序节点（PERSISTENT_SEQUENTIAL）
所谓顺序节点，就是在创建节点时，Zookeeper根据创建的时间顺序给该节点名称进行编号：
3.临时节点（EPHEMERAL）
和持久节点相反，当创建节点的客户端与zookeeper断开连接后，临时节点会被删除：
4.临时顺序节点（EPHEMERAL_SEQUENTIAL）
顾名思义，临时顺序节点结合和临时节点和顺序节点的特点：在创建节点时，Zookeeper根据创建的时间顺序给该节点名称进行编号；当创建节点的客户端与zookeeper断开连接后，临时节点会被删除。
问题及解决方法
| 问题 | 解决方法 |
| 锁无法释放 | Zookeeper可以有效的解决锁无法释放的问题，因为在创建锁的时候，客户端会在ZK中创建一个临时节点，一旦客户端获取到锁之后突然挂掉（Session连接断开），那么这个临时节点就会自动删除掉。其他客户端就可以再次获得锁。 |
| 非阻塞锁 | Zookeeper可以实现阻塞的锁，客户端可以通过在ZK中创建顺序节点，并且在节点上绑定监听器，一旦节点有变化，Zookeeper会通知客户端，客户端可以检查自己创建的节点是不是当前所有节点中序号最小的，如果是，那么自己就获取到锁，便可以执行业务逻辑了。 |
| 不可重入 | Zookeeper也可以有效的解决不可重入的问题，客户端在创建节点的时候，把当前客户端的主机信息和线程信息直接写入到节点中，下次想要获取锁的时候和当前最小的节点中的数据比对一下就可以了。如果和自己的信息一样，那么自己直接获取到锁，如果不一样就再创建一个临时的顺序节点，参与排队。 |
| 单点问题 | Zookeeper可以有效的解决单点问题，ZK是集群部署的，只要集群中有半数以上的机器存活，就可以对外提供服务。 |
| 公平问题 | Zookeeper可以解决公平锁问题，客户端在ZK中创建的临时节点是有序的，每次锁被释放时，ZK可以通知最小节点来获取锁，保证了公平。 |
| 一致性问题 | Zookeeper是一个保证了弱一致性即最终一致性的分布式组件。 |
优点
- 有效解决这些问题：单点，不可重入，非阻塞、锁无法释放（不靠超时时间释放锁）。
- 实现简单。
- 可靠性高。
缺点
- 性能不如Redis
一致性
Zookeeper采用称为Quorum Based Protocol的数据同步协议。假如Zookeeper集群有N台Zookeeper服务器(N通常取奇数，3台能够满足数据可靠性同时有很高读写性能，5台在数据可靠性和读写性能方面平衡最好)，那么用户的一个写操作，首先同步到N/2 + 1台服务器上，然后返回给用户，提示用户写成功。基于Quorum Based Protocol的数据同步协议决定了Zookeeper能够支持什么强度的一致性。
在分布式环境下，满足强一致性的数据储存基本不存在，它要求在更新一个节点的数据，需要同步更新所有的节点。这种同步策略出现在主从同步复制的数据库中。但是这种同步策略，对写性能的影响太大而很少见于实践。因为Zookeeper是同步写N/2+1个节点，还有N/2个节点没有同步更新，所以Zookeeper不是强一致性的。
用户的数据更新操作，不保证后续的读操作能够读到更新后的值，但是最终会呈现一致性。牺牲一致性，并不是完全不管数据的一致性，否则数据是混乱的，那么系统可用性再高分布式再好也没有了价值。牺牲一致性，只是不再要求关系型数据库中的强一致性，而是只要系统能达到最终一致性即可。
Zookeeper是否满足最终一致性，需要看客户端的编程方式
满足最终一致性编程的方法
- B进程监听Zookeeper上/z的数据变化
- A进程向Zookeeper的/z写入一个数据，成功返回前，Zookeeper需要调用注册在/z上的监听器，Leader将数据变化的通知告诉B
- B进程的事件响应方法得到响应后，去取变化的数据，那么B一定能够得到变化的值
- 这里的因果一致性提现在Leader和B之间的因果一致性，也就是是Leader通知了数据有变化
不满足最终一致性编程的方法
- A进程向Zookeeper的/z写入一个数据，成功返回
- A进程通知B进程，A已经修改了/z的数据
- B读取Zookeeper的/z的数据
- 由于B连接的Zookeeper的服务器有可能还没有得到A写入数据的更新，那么B将读不到A写入的数据
Zookeeper分布式锁的原理
Zookeeper分布式锁应用了临时顺序节点。具体如何实现呢？让我们来看一看详细步骤：
获取锁
首先，在Zookeeper当中创建一个持久节点ParentLock。当第一个客户端（Client1）想要获得锁时，需要在ParentLock这个节点下面创建一个临时顺序节点 Lock1。
之后，Client1查找ParentLock下面所有的临时顺序节点并排序，判断自己所创建的节点Lock1是不是顺序最靠前的一个。如果是第一个节点，则成功获得锁。
这时候，如果再有一个客户端 Client2 前来获取锁，则在ParentLock下载再创建一个临时顺序节点Lock2。
Client2查找ParentLock下面所有的临时顺序节点并排序，判断自己所创建的节点Lock2是不是顺序最靠前的一个，结果发现节点Lock2并不是最小的。
于是，Client2向排序仅比它靠前的节点Lock1注册Watcher，用于监听Lock1节点是否存在。这意味着Client2抢锁失败，进入了等待状态。
这时候，如果又有一个客户端Client3前来获取锁，则在ParentLock下载再创建一个临时顺序节点Lock3。
Client3查找ParentLock下面所有的临时顺序节点并排序，判断自己所创建的节点Lock3是不是顺序最靠前的一个，结果同样发现节点Lock3并不是最靠前的。
于是，Client3向排序仅比它靠前的节点Lock2注册Watcher，用于监听Lock2节点是否存在。这意味着Client3同样抢锁失败，进入了等待状态。
这样一来，Client1得到了锁，Client2监听了Lock1，Client3监听了Lock2。这恰恰形成了一个等待队列，很像是Java当中ReentrantLock所依赖的AQS。
锁的续期
为了保持客户端会话的有效性，在ZooKeeper的运行过程中，客户端会在会话超时时间过期范围内向服务端发送P1NG请求来保持会话的有效性，我们俗称“心跳检测”。同时，服务端需要不断地接收来自客户端的这个心跳检测，并且需要重新激活对应的客户端会话，我们将这个重新激活的过程称为TouchSession。会话激活的过程，不仅能够使服务端检测到对应客户端的存活性，同时也能让客户端自己保持连接状态。
- 检验该会话是否已经被关闭。
- Leader会检査该会话是否已经被关闭，如果该会话已经被关闭，那么不再继续激活该会话。
- 计算该会话新的超时时间ExpirationTime_New。
- 如果该会话尚未关闭，那么就开始激活会话。
- 首先需要计算出该会话下一次超时时间点，使用的就是上面提到的计算公式。
- 定位该会话当前的区块。
- 获取该会话老的超时时间Expirati〇nTime_01d，并根据该超时时间来定位到其所在的区块。
- 迁移会话
- 将该会话从老的区块中取出，放入ExpirationTime_New对应的新区块中 ，如图2所示
通过以上4步，就基本完成会话激活的过程。
在上面的会话激活过程中，我们可以看到，只要客户端发来心跳检测，那么服务端就会进行一次会话激活。心跳检测由客户端主动发起，以PING请求的形式向服务端发送。但实际上，在ZooKeeper服务端的设计中，只要客户端有请求发送到服务端，那么就会触发一次会话激活。因此，总的来讲，大体会出现以下两种情况下的会话激活。
- 只要客户端向服务端发送请求，包括读或写请求，那么就会触发一次会话激活。
- 如果客户端发现在sessionTimeout/3时间内尚未和服务器进行过任何通信，即没有向服务端发送任何请求，那么就会主动发起一个PING请求，服务端收到该请求后，就会触发上述第一种情况下的会话激活。
释放锁
释放锁分为两种情况：
1.任务完成，客户端显示释放
当任务完成时，Client1会显示调用删除节点Lock1的指令。
2.任务执行过程中，客户端崩溃
获得锁的Client1在任务执行过程中，如果崩溃，则会断开与Zookeeper服务端的链接。根据临时节点的特性，相关联的节点Lock1会随之自动删除。
由于Client2一直监听着Lock1的存在状态，当Lock1节点被删除，Client2会立刻收到通知。这时候Client2会再次查询ParentLock下面的所有节点，确认自己创建的节点Lock2是不是目前最小的节点。如果是最小，则Client2顺理成章获得了锁。
同理，如果Client2也因为任务完成或者节点崩溃而删除了节点Lock2，那么Client3就会接到通知。
最终，Client3成功得到了锁。
问答
获得了锁的JVM，一直不释放锁如何处理
可以控制续命的次数，如果续命多次还是没有释放锁的话，则会超时自动释放锁，并且回滚当前事务的操作。
请先 ！