分布式锁的实现

什么是分布式锁？

为了保证一个方法或属性在高并发情况下的同一时间只能被同一个线程执行，在传统单体应用单机部署的情况下，可以使用Java并发处理相关的API(如ReentrantLock或Synchronized)进行互斥控制。在单机环境中，Java中提供了很多并发处理相关的API。
但是，随着业务发展的需要，原单体单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，单纯的Java API并不能提供分布式锁的能力。
为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题！

分布式锁应该具备的条件

在分布式系统环境下，一个方法在同一时间只能被一个机器的一个线程执行；
高可用的获取锁与释放锁；
高性能的获取锁与释放锁；
具备可重入特性；
具备锁失效机制，防止死锁；
具备非阻塞锁特性，即没有获取到锁将直接返回获取锁失败。

基于Redis实现的分布式锁

使用setnx命令实现分布式锁
setNx:当且仅当 key 不存在，将 key 的值设为 value ，并返回1；若给定的 key 已经存在，则 SETNX 不做任何动作，并返回0。
如果 SETNX 返回1，说明该进程获得锁，SETNX将键 lock.foo 的值设置为锁的超时时间（当前时间 + 锁的有效时间）。
如果 SETNX 返回0，说明其他进程已经获得了锁，进程不能进入临界区。进程可以在一个循环中不断地尝试 SETNX 操作，以获得锁。
上面的例子很容易产生死锁，并且 setnx和expire(设置超时时间)不是原子操作，当setnx后，redis宕掉，则此锁无法释放掉！
故我们谈到redis分布式锁实现，更多使用set来获取锁，lua脚本来释放锁，由于set是原子操作，可以达到setNX同时设置expire的效果

Redis分布式锁存在的问题

锁超时
如果在加锁和释放锁之间，业务逻辑执行时间太长，导致超出了锁的超时限制，就会出现锁过期问题；
换句话说，就是第一台应用执行了业务，导致锁过期；第二台应用此时可以获得锁，进行执行业务，此时第一台应用释放了锁，第二台应用在执行业务的时第三台应用获得了锁执行业务，导致在执行过程中，会有2台应用在同时执行业务逻辑；
解决思路：
在释放锁的时候出现了问题，即每台应用都可以释放锁，这会造成1应用的锁释放了2应用锁的问题，换句话说，很多人手中持有的钥匙是通用的，都可以开同一个门；
为了避免这个问题，就是1 应用只能释放1应用上的锁，2应用只能释放2应用上的锁，则需要对释放锁进行身份校验；
由于上锁的时候key是唯一，但value可以不同，所以可以根据value进行身份的唯一标识，随机数就是一个很好的选择；

关于看门狗：
redisson中提供了看门狗机制，对锁超时的情况进行处理，进行了锁的自动延期，但是博主在其他地方看到有说watch dog只有针对没有设置过期时间的锁才会使用，由于目前工作中更多使用的是基于zk实现的分布式锁，故此处暂时保留，日后补充。

基于Zookeeper实现的分布式锁

zookeeper的节点分为四种：

持久节点
默认的节点类型。创建节点的客户端与zookeeper断开连接后，该节点依旧存在。
顺序持久节点
在创建节点时，Zookeeper根据创建的时间顺序给该节点名称进行编号
临时节点
当创建节点的客户端与zookeeper断开连接后，临时节点会被删除
临时顺序节点
在创建节点时，Zookeeper根据创建的时间顺序给该节点名称进行编号；当创建节点的客户端与zookeeper断开连接后，临时节点会被删除。

zookeeper实现分布式锁依靠的是临时顺序节点

获取锁

首先，在Zookeeper当中创建一个持久节点ParentLock。当第一个客户端想要获得锁时，需要在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同样抢锁失败，进入了等待状态。