什么是分布式锁？
为了保证一个方法或属性在高并发情况下的同一时间只能被同一个线程执行，在传统单体应用单机部署的情况下，可以使用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同样抢锁失败，进入了等待状态。
这样一来，Client1得到了锁，Client2监听了Lock1，Client3监听了Lock2。这恰恰形成了一个等待队列，很像是Java当中ReentrantLock所依赖的
释放锁
释放锁分为两种情况
- 任务完成,客户端显示释放
当任务完成时，Client1会显式调用删除节点Lock1的指令。
-
任务执行过程中,客户端崩溃
-
获得锁的Client1在任务执行过程中，如果Duang的一声崩溃，则会断开与Zookeeper服务端的链接。根据临时节点的特性，相关联的节点Lock1会随之自动删除。
- 由于Client2一直监听着Lock1的存在状态，当Lock1节点被删除，Client2会立刻收到通知。这时候Client2会再次查询ParentLock下面的所有节点，确认自己创建的节点Lock2是不是目前最小的节点。如果是最小，则Client2顺理成章获得了锁。
- 同理，如果Client2也因为任务完成或者节点崩溃而删除了节点Lock2，那么Client3就会接到通知。
在curator中是通过InterProcessMutex类去实现的分布式锁。
参考链接
三种实现分布式锁的方式—夏目
redis 分布式锁setnx的缺陷与替代方案
Original: https://www.cnblogs.com/winter0730/p/15543443.html
Author: cos晓风残月
Title: 分布式锁的实现
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/576244/
转载文章受原作者版权保护。转载请注明原作者出处！