Redis 分布式锁的原理以及如何续期，java 程序设计实验实训教程答案

因为一大坨复杂的业务逻辑，可以通过封装在 lua 脚本中发送给 redis，保证这段复杂业务逻辑执行的原子性。 那么，这段 lua 脚本是什么意思呢？ **KEYS\[1\]**代表的是你加锁的那个 key，比如说： RLock lock = redisson.getLock("myLock"); 这里你自己设置了加锁的那个锁 key 就是“myLock”。 **ARGV\[1\]**代表的就是锁 key 的默认生存时间，默认 30 秒。 **ARGV\[2\]**代表的是加锁的客户端的 ID，类似于下面这样： 8743c9c0-0795-4907-87fd-6c719a6b4586:1 给大家解释一下，第一段 if 判断语句，就是用“exists myLock”命令判断一下，如果你要加锁的那个锁 key 不存在的话，你就进行加锁。 如何加锁呢？很简单，用下面的命令： hset myLock? 8743c9c0-0795-4907-87fd-6c719a6b4586:1 1 通过这个命令设置一个 hash 数据结构，这行命令执行后，会出现一个类似下面的数据结构：  上述就代表“8743c9c0-0795-4907-87fd-6c719a6b4586:1”这个客户端对“myLock”这个锁 key 完成了加锁。 接着会执行“pexpire myLock 30000”命令，设置 myLock 这个锁 key 的生存时间是 30 秒。 好了，到此为止，ok，加锁完成了。 **（2）锁互斥机制** 那么在这个时候，如果客户端 2 来尝试加锁，执行了同样的一段 lua 脚本，会咋样呢？ 很简单，第一个 if 判断会执行“exists myLock”，发现 myLock 这个锁 key 已经存在了。 接着第二个 if 判断，判断一下，myLock 锁 key 的 hash 数据结构中，是否包含客户端 2 的 ID，但是明显不是的，因为那里包含的是客户端 1 的 ID。 所以，客户端 2 会获取到 pttl myLock 返回的一个数字，这个数字代表了 myLock 这个锁 key 的剩余生存时间。比如还剩 15000 毫秒的生存时间。 此时客户端 2 会进入一个 while 循环，不停的尝试加锁。 **（3）watch dog 自动延期机制** 客户端 1 加锁的锁 key 默认生存时间才 30 秒，如果超过了 30 秒，客户端 1 还想一直持有这把锁，怎么办呢？ 简单！只要客户端 1 一旦加锁成功，就会启动一个 watch dog 看门狗，**他是一个后台线程，会每隔 10 秒检查一下**，如果客户端 1 还持有锁 key，那么就会不断的延长锁 key 的生存时间。 **（4）可重入加锁机制** 那如果客户端 1 都已经持有了这把锁了，结果可重入的加锁会怎么样呢？ 比如下面这种代码：  这时我们来分析一下上面那段 lua 脚本。 第一个 if 判断肯定不成立，“exists myLock”会显示锁 key 已经存在了。 第二个 if 判断会成立，因为 myLock 的 hash 数据结构中包含的那个 ID，就是客户端 1 的那个 ID，也就是“8743c9c0-0795-4907-87fd-6c719a6b4586:1” 此时就会执行可重入加锁的逻辑，他会用： incrby myLock? 8743c9c0-0795-4907-87fd-6c71a6b4586:1 1 通过这个命令，对客户端 1 的加锁次数，累加 1。 此时 myLock 数据结构变为下面这样：  大家看到了吧，那个 myLock 的 hash 数据结构中的那个客户端 ID，就对应着加锁的次数 **（5）释放锁机制** 如果执行 lock.unlock()，就可以释放分布式锁，此时的业务逻辑也是非常简单的。 其实说白了，就是每次都对 myLock 数据结构中的那个加锁次数减 1。 如果发现加锁次数是 0 了，说明这个客户端已经不再持有锁了，此时就会用： “del myLock”命令，从 redis 里删除这个 key。 然后呢，另外的客户端 2 就可以尝试完成加锁了。 这就是所谓的**分布式锁的开源 Redisson 框架的实现机制**。 一般我们在生产系统中，可以用 Redisson 框架提供的这个类库来基于 redis 进行分布式锁的加锁与释放锁。 **（6）Redis 分布式锁的缺点** 其实上面那种方案最大的问题，就是如果你对某个 redis master 实例，写入了 myLock 这种锁 key 的 value，此时会异步复制给对应的 master slave 实例。 但是这个过程中一旦发生 redis master 宕机，主备切换，redis slave 变为了 redis master。 接着就会导致，客户端 2 来尝试加锁的时候，在新的 redis master 上完成了加锁，而客户端 1 也以为自己成功加了锁。 此时就会导致多个客户端对一个分布式锁完成了加锁。 这时系统在业务语义上一定会出现问题，**导致各种脏数据的产生**。 所以这个就是 redis cluster，或者是 redis master-slave 架构的**主从异步复制**导致的 redis 分布式锁的最大缺陷：在 redis master 实例宕机的时候，可能导致多个客户端同时完成加锁。 **（7）Redis 红锁** Redis 作者针对 Redis 分布式锁的缺点提出了红锁的概念算法如下： > 1. 顺序向五个节点请求加锁 > 2. 根据一定的**超时时间**来推断是不是跳过该节点 > 3. ``` 《Android 学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》 浏览器打开：qq.cn.hn/FTe 免费领取 ``` 三个节点加锁成功并且花费时间小于锁的有效期 > 4. 认定加锁成功  也就是说，假设锁 30 秒过期，三个节点加锁花了 31 秒，自然是加锁失败了。这只是举个例子，实际上并不应该等每个节点那么长时间，就像官网所说的那样，假设有效期是 10 秒，那么单个 redis 实例操作超时时间，应该在 5 到 50 毫秒(注意时间单位)还是假设我们设置有效期是 30 秒，图中超时了两个 redis 节点。那么加锁成功的节点总共花费了 3 秒，所以锁的实际有效期是小于 27 秒的。即扣除加锁成功三个实例的 3 秒，还要扣除等待超时 redis 实例的总共时间。 关于红锁的争论：Martin Kleppmann 和 antirez 的 redLock 辩论. 一个是很有资历的分布式架构师，一个是 redis 之父。 所以说如果项目里要使用红锁，除了红锁的介绍，不妨要多看两篇文章，即：