锁重试和续约? Redisson: 不错, 正是在下 (源码解读)-阿里云开发者社区

锁重试和续约? Redisson: 不错, 正是在下 (源码解读)

2023-05-25 1332

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

本文涉及的产品

云数据库 Tair（兼容Redis），内存型 2GB

Redis 开源版，标准版 2GB

简介： 这是最详细的Redisson锁重入, 锁重试, Watchdog看门狗, 锁续约机制源码讲解Redisson分布式锁原理：可重入：利用hash结构记录线程id和重入次数可重试：利用信号量和PubSub功能实现等待、唤醒，获取锁失败的重试机制超时续约：利用watchDog，每隔一段时间（releaseTime), 重置超时时间

♨️本篇文章记录的为Redisson 相关内容，适合在学Java的小白,帮助新手快速上手,也适合复习中，面试中的大佬🙉🙉🙉。
♨️如果文章有什么需要改进的地方还请大佬不吝赐教❤️🧡💛
👨‍🔧 个人主页 : 阿千弟
⚡> 点击这里👉👉👉 : Redis专栏学习

@[toc]

🍓为什么使用Redisson

应用场景

请求 a 的锁过期，但其业务还未执行完毕；请求 b 申请到了锁，其也正在处理业务。如果此时两个请求都同时修改了共享的库存数据，那么就又会出现数据不一致的问题，即仍然存在并发问题。在高并发场景下，问题会被无限大。
### 问题解决

对于该问题，可以采用“锁续约”方式解决。

在当前业务进程开始执行时，fork 出一个子进程，用于启动一个定时任务。
该定时任务的定时时间小于锁的过期时间，其会定时查看处理当前请求的业务进程的锁是否已被删除。
如果已被删除，则子进程结束；如果未被删除，说明当前请求的业务还未处理完毕，则将锁的时间重新设置为“原过期时间”。
这种方式称为锁续约，也称为锁续命。

使用 Redisson 的可重入锁可以解决上述问题。

Redisson 内部使用 Lua 脚本实现了对可重入锁的添加、重入、续约（命）、释放。Redisson需要用户为锁指定一个 key，但无需为锁指定过期时间，因为它有默认过期时间(当然，也可指定)。由于该锁具有“可重入”功能，所以 Redisson 会为该锁生成一个计数器，记录一个线程重入锁的次数。

在这里插入图片描述

## 🍉了解Redisson

### Redisson 简介
在生产中，对于 Redisson 使用最多的场景就是其分布式锁 RLock。当然，RLock 仅仅是Redisson 的线程同步方案之一。Redisson 提供了 8 种线程同步方案，用户可针对不同场景选用不同方案。

需要注意的是，为了避免锁到期但业务逻辑没有执行完毕而引发的多个线程同时访问共享资源的情况发生，Redisson 内部为锁提供了一个监控锁的看门狗 watch dog，其会在锁到期前不断延长锁的到期时间，直到锁被主动释放。即会自动完成“锁续命”。

### 可重入锁
Redisson 的分布式锁 RLock 是一种可重入锁。当一个线程获取到锁之后，这个线程可以再次获取本对象上的锁，而其他的线程是不可以的。
- JDK 中的 ReentrantLock 是可重入锁，其是通过 AQS(抽象队列同步器)实现的锁机制
- synchronized 也是可重入锁，其是通过监视器模式(本质是 OS 的互斥锁)实现的锁机制

## 🍅Redisson的锁重入源码解读
### 废话不多说, 我们直接进入源码

在这里插入图片描述

waitTime : 获取锁的最大等待时长, 第一次获取锁失败不会立即返回, 而是在等待时间内不断的尝试, 如果这个时间结束了都还没获取成功, 才返回false
lease : 锁自动失效释放的时间
unit : 时间单位

点进去查看 tryAcquire 发现内部调用的是 tryAcquireAsync

在这里插入图片描述
查看 tryAcquireAsync 内部方法

在这里插入图片描述

查看 tryLockInnerAsync 内部方法

在这里插入图片描述

lua脚本部分执行成功返回的是nil (类似于我们java中的null), 执行失败了反而返回一个结果 : redis.call ( 'pttl', KEYS[1] ) 也就是锁的剩余的有效期

执行了pttl命令, KEYS[1]是锁的名称, pttl和ttl效果是类似的, 都是获取key的剩余有效期, 只不过ttl返回的是s为单位, pttl返回的是ms为单位

现在已经拿到了锁的有效期, 我们现在往回倒一步

在这里插入图片描述

把RFuture返回以后, 这里就有回到了这里 get(tryAcquireAsync((wait, leaseTime, threadId))
get方法就是获取阻塞等待RFuther结果, 等待得到的剩余有效期

在这里插入图片描述

这时就回到了这里

在这里插入图片描述

这里的subscribe就是订阅释放锁的lua脚本中的publish
如果等待结束还没有收到通知就取消订阅, 并返回获取锁失败

在这里插入图片描述

java if (ttl>=0 && ttl < time)
- ttl小于time(等待时间), 代表在等待之间锁就已经释放了
- ttl大于time(等待时间), 如果等了time的时间, 经过time的时间,锁还没有被释放, 也就没必要等了

在这里插入图片描述

如果时间还很充足, 就继续while(true)执行上面的代码, 不停的尝试等待,不断的进行这样的循环

这里设计的巧妙之处就在于利用了消息订阅, 信号量的机制, 它不是无休止的这种盲等机制, 也避免了不断的重试, 而是检测到锁被释放才去尝试重新获取, 这对CPU十分的友好

在这里插入图片描述

## 🍊WatchDog续约(续命)源码解读
### 场景
Redisson锁重试的问题是解决了, 但是总会发生一些问题, 如果我们的业务阻塞超时了ttl到期了, 别的线程看见我们的ttl到期了, 他重试他就会拿到本该属于我们的锁, 这时候就有安全问题了, 所以该怎么解决?

我们必须确保锁是业务执行完释放的, 而不是因为阻塞而释放的
### 进入源码

我们再次来看这段代码
在这里插入图片描述

当我们没有设置leaseTime的时候, 也就是leaseTime=-1的时候就用看门狗过期时间来获取锁
watchTimeout默认时间是30s

在这里插入图片描述

当ttlRemainingFuture的异步尝试获取锁完成以后, 先判断执行过程中是否有异常, 如果有异常就直接返回了结束执行.
如果没有发生异常, 则判断ttlRemaining(剩余有效期)是否为空, 为空的话就代表获取锁成功, 执行锁到期续约的核心方法scheduleExpectationRenew

进入scheduleExpectationRenew方法中查看

在这里插入图片描述

这里面的EXPIRATION_RENEWAL_MAP中的key很有意思, 我们进去看一下

在这里插入图片描述
清楚的发现 entryName由 id 和 name 两部分组成
id就是当前的这个连接的id, name 就是当前锁的名称

在这里插入图片描述

这就好办了, 我们可以这样理解getEntryName获得的就是锁的名称, 而这个EXPIRATION_RENEWAL_MAP是静态的, 那么RedissonLock类的所有实例就都可以看到这个map
而一个RedissonLock类可以创建出很多锁的实例, 每一个锁都会有自己的名字, 那么在这个map中就会有唯一的key也就是getEntryName()与唯一的entry相对应

如果是第一次创建entry往map里放的时候, 这个entry肯定不存在, 所以调用的是putIfAbsent, 这时候往map中放入的就是一个全新的entry, 返回值就是null
如果不是第一次放入,放入的是重入的entry的话, putIfAbsent返回的就是旧的oldEntry