乐趣区

关于redis:Redisson-分布式锁实现原理

应用

加锁机制

lock()底层是通过一段 lua 脚本实现的

KEYS[1] 代表你加锁的那个 key,RLock lock = redisson.getLock(“myLock”); 这里你本人设置了加锁的那个锁 key 就是“myLock”
ARGV[1]代表的就是锁 key 的默认生存工夫,默认 30 秒
ARGV[2] 代表的是加锁的客户端的 ID,相似于上面这样:8743c9c0-0795-4907-87fd-6c719a6b4586:1
加锁流程:
1. 判断是否存在这个加锁的 key
2. 如果不存在,通过 hset 命令加锁
3. 设置过期工夫

锁互斥机制

如果客户端 2 来尝试加锁,执行了同样的一段 lua 脚本。
1. 第一个 if 判断这个 key 发现已存在,走第二个 if 判断 key 中的客户端的 id 是否与是客户端 2 的 id
2. 如果发现不是,客户端 2 会获取到 pttl myLock 返回的一个数字,这个数字代表了 myLock 这个锁 key 的 残余生存工夫。比方还剩 15000 毫秒的生存工夫。此时客户端 2 会进入一个 while 循环,不停的尝试加锁。
实际上的原理:
当锁正在被占用时,期待获取锁的过程并不是通过一个 while(true) 死循环去获取锁,而是利用了 Redis 的公布订阅机制, 通过 await 办法阻塞期待锁的过程,无效的解决了 有效的锁申请浪费资源的问题

watch dog 主动延期机制

客户端 1 加锁的锁 key 默认生存工夫才 30 秒,如果超过了 30 秒,客户端 1 还想始终持有这把锁,怎么办呢?
简略!只有客户端 1 一旦加锁胜利,就会启动一个 watch dog 看门狗,他是一个后盾线程,会每隔 10 秒检查一下,如果客户端 1 还持有锁 key,过期工夫持续缩短为 30s。

可重入加锁机制


下面那段 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 8743c9c0-0795-4907-87fd-6c71a6b4586:1 2

锁开释机制

如果执行 lock.unlock(),就能够开释分布式锁,此时的业务逻辑也是非常简单的。其实说白了,就是每次都对 myLock 数据结构中的那个加锁次数减 1。如果发现加锁次数是 0 了,阐明这个客户端曾经不再持有锁了,此时就会用:“del myLock”命令,从 redis 里删除这个 key

此种计划 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 实例宕机的时候,可能导致多个客户端同时实现加锁

参考大佬:
托付,面试请不要再问我 Redis 分布式锁的实现原理!

退出移动版