写点什么

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

作者:Java高工P7
  • 2021 年 11 月 10 日
  • 本文字数:2387 字

    阅读完需:约 8 分钟

因为一大坨复杂的业务逻辑,可以通过封装在 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 数据结构,这行命令执行后,会出现一个类似下面的数据结构: ![](https://static001.geekbang.org/infoq/32/328f0cefccb53fb0d6a68244aa7b199b.jpeg) 上述就代表“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 都已经持有了这把锁了,结果可重入的加锁会怎么样呢? 比如下面这种代码: ![](https://static001.geekbang.org/infoq/e7/e75fec783ca1318b41f75f88fb2cc959.png) 这时我们来分析一下上面那段 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 数据结构变为下面这样: ![](https://static001.geekbang.org/infoq/15/154f2a3ddb722e1de9ff14618b3f5e03.jpeg) 大家看到了吧,那个 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. 认定加锁成功 ![](https://static001.geekbang.org/infoq/41/41b3ed82fa722afad2c297dbaaa56120.jpeg) 也就是说,假设锁 30 秒过期,三个节点加锁花了 31 秒,自然是加锁失败了。这只是举个例子,实际上并不应该等每个节点那么长时间,就像官网所说的那样,假设有效期是 10 秒,那么单个 redis 实例操作超时时间,应该在 5 到 50 毫秒(注意时间单位)还是假设我们设置有效期是 30 秒,图中超时了两个 redis 节点。那么加锁成功的节点总共花费了 3 秒,所以锁的实际有效期是小于 27 秒的。即扣除加锁成功三个实例的 3 秒,还要扣除等待超时 redis 实例的总共时间。 关于红锁的争论:Martin Kleppmann 和 antirez 的 redLock 辩论. 一个是很有资历的分布式架构师,一个是 redis 之父。 所以说如果项目里要使用红锁,除了红锁的介绍,不妨要多看两篇文章,即:

用户头像

Java高工P7

关注

还未添加个人签名 2021.11.08 加入

还未添加个人简介

评论

发布
暂无评论
Redis分布式锁的原理以及如何续期,java程序设计实验实训教程答案