参考：
1，Redisson实现Redis分布式锁的N种姿势
2，Redlock：Redis分布式锁最牛逼的实现
3，Redis全面解析三：redis分布式锁的实现原理你了解吗
4，Redis分布式锁的底层原理

推荐参考：Redis中是如何实现分布式锁的？

Redisson这个框架对Redis分布式锁的实现原理图如下：

redis分布式锁 是一个 渐进的过程 首先setnx这个命令 之后要被淘汰了，现在平时说的setnx指的是 set key value px milliseconds nx 这个命令 这个是原子的，但是只要这一个命令是不行的，在解锁的时候 不是原子的，需要借助lua脚本，即eval命令执行lua脚本。这时就可以引入 redssion了，redssion有两种锁实现。

1. 加锁：set key value px milliseconds nx，这个命令 这个是原子的；
2. 解锁：需要借助lua脚本，即eval命令执行lua脚本
   value要具有唯一性，释放锁时要验证value值，不能误解锁；

事实上这类琐最大的缺点就是它加锁时只作用在一个Redis节点上，即使Redis通过sentinel保证高可用，如果这个master节点由于某些原因发生了主从切换，那么就会出现锁丢失的情况：

1. 在Redis的master节点上拿到了锁；
2. 但是这个加锁的key还没有同步到slave节点；
3. master故障，发生故障转移，slave节点升级为master节点；
4. 导致锁丢失。

这时 就引出 redission基于 redlock算法，redisson redlock 就解决了这个问题；它的不足是需要额外引入一套redis节点 满足多节点加锁的特性
在Redis的分布式环境中，我们假设有N个Redis master。这些节点完全互相独立，不存在主从复制或者其他集群协调机制。我们确保将在N个实例上使用与在Redis单实例下相同方法获取和释放锁。现在我们假设有5个Redis master节点，同时我们需要在5台服务器上面运行这些Redis实例，这样保证他们不会同时都宕掉。

为了取到锁，客户端应该执行以下操作:

• 获取当前Unix时间，以毫秒为单位。

• 依次尝试从5个实例，使用相同的key和具有唯一性的value（例如UUID）获取锁。当向Redis请求获取锁时，客户端应该设置一个网络连接和响应超时时间，这个超时时间应该小于锁的失效时间。例如你的锁自动失效时间为10秒，则超时时间应该在5-50毫秒之间。这样可以避免服务器端Redis已经挂掉的情况下，客户端还在死死地等待响应结果。如果服务器端没有在规定时间内响应，客户端应该尽快尝试去另外一个Redis实例请求获取锁。

• 客户端使用当前时间减去开始获取锁时间（步骤1记录的时间）就得到获取锁使用的时间。当且仅当从大多数（N/2+1，这里是3个节点）的Redis节点都取到锁，并且使用的时间小于锁超时时间时，锁才算获取成功。

• 如果取到了锁，key的真正有效时间等于有效时间减去获取锁所使用的时间（步骤3计算的结果）。

• 如果因为某些原因，获取锁失败（没有在至少N/2+1个Redis实例取到锁或者取锁时间已经超过了有效时间），客户端应该在所有的Redis实例上进行解锁（即便某些Redis实例根本就没有加锁成功，防止某些节点获取到锁但是客户端没有得到响应而导致接下来的一段时间不能被重新获取锁）。