Redisson 实现分布式锁源码浅析

大家好，我是此林。

今天来分享Redisson分布式锁源码。还是一样，我们用 问题驱动 的方式展开讲述。

1. redis 中如何使用 lua 脚本？

Redis内置了lua解释器，lua脚本有两个好处：

1. 减少多次Redis命令的网络传输开销。（当然也可以使用pipline命令）

2. lua脚本所有命令能保证原子性，隔离性（Redis单线程），失败回滚

综上所述，Redis中如果想要实现事务操作，可以使用lua脚本。

Redis 本身也可以使用 MULTI + WATCH乐观锁 来实现，但是它只能保证命令执行的顺序性，无法保证失败回滚，无法保证原子性。

所以，一般推荐使用 lua 脚本。

使用案例：

现在我们要去执行redis命令：

HSET info name john

1. lua脚本

local hash_key = KEYS[1]    -- 哈希结构的键名（外部传入）
local key = ARGV[1]         -- 哈希字段（外部传入）
local value = ARGV[2]       -- 哈希字段值（外部传入）return redis.call('HSET', hash_key, key, value)

因为KEYS[1]、ARGV[1]等都是外部传入，所以可以简化。

return redis.call('HSET', KEYS[1], ARGV[1], ARGV[2])

redis.call()就是执行redis命令。

2. redis 命令

EVAL "return redis.call('HSET', KEYS[1], ARGV[1], ARGV[2])" 1 info name john

这里的1代表传入一个key。

2. 如何使用Redisson？

这里的

boolean isLock = lock.tryLock(1, 10, TimeUnit.SECONDS);

是获取锁，第一个1表示：锁超时等待时间，在1秒内会不断重试获取锁，直到获取到。

第二个10表示：锁释放时间，为10秒（防止java服务获取到锁后，突然宕机，导致redis锁永远不会被释放，避免造成死锁问题。）

3. Redisson源码？

3.1. Redisson如何实现锁重入？

其实归根结底，就是这段代码。Redisson本质上是使用hash结构来标志锁的，可能我们经常听到说用setnx命令来实现分布式锁，但是setnx无法实现锁的重入。

所以Redisson用 hash（计数） + lua脚本（原子性）实现可重入分布式锁。

先说明下参数：

KEYS[1]：hash结构的键名，也就是我们之前手动指定的 anylock

ARGV[1]：锁的释放时间

ARGV[2]：hash结构的字段的键名，UUID:线程id

我们直接去看redis：

anyLock这个hash结构里，

有字段的key为c3341b71-6edd-4db8-b626-9135cf727fd4:1，value为1

了解了锁的结构后，我们再来看lua脚本。

一图胜千言，总的来说，

第一个if：处理线程第一次获取锁

第二个if：处理线程重入获取锁

最后：发现锁已经被占有，返回剩余ttl（过期时间）。

3.2. 如果抢锁失败呢？

之前说的锁的设置，其实就是图中框起来的方法里的实现。

接下来，如果ttl为null，抢锁成功了，直接返回true。

如果ttl不为null，说明抢锁失败了，会去计算等待时间是否充足。

这里的等待时间就是我们之前手动设置的1秒钟。

如果锁等待时间还充足，那么执行它会去用pub-sub机制去 订阅锁释放事件。（避免轮询 Redis 造成的性能损耗。）

如果订阅超时，触发失败回调，返回false。

那么订阅成功了之后呢？会再次尝试抢锁。

还不行，那只能信号量挂起，具体通过 Semaphore（getLatch()）挂起当前线程，等待锁释放的 Pub/Sub 通知。

总结一下抢锁流程：

抢锁成功，直接返回；抢锁失败，pub/sub机制订阅锁释放事件，通过信号量挂起线程，直到收到锁释放的消息才被唤醒。

3.3. 解锁流程是怎么样的？

看下图。本质还是那一段lua脚本。

先看下锁是不是线程自己的，不是的话直接返回null。

如果锁是自己的，计数器减1。

如果减1操作后还大于0，说明重入的还没完，刷新锁的超时释放时间。

如果减1后小于等于0，直接删除，发布锁删除事件。

返回nil表示锁不属于当前线程，应抛出异常。
返回0表示锁未完全释放，仅更新了过期时间。
返回1表示锁已释放，并发布事件。

3.4. Redisson的看门狗机制？

看门狗主要用于 解决锁的自动续期问题，避免因业务执行时间过长导致锁超时自动释放。

注意一点：如果我们显式指定了leaseTime参数，看门狗机制就不会生效。这时候锁的过期时间由用户控制。

像我们之前手动指定了锁释放时间10秒，它就不会走看门狗机制，Redisson默认锁释放时间是30秒。（见下图，单位毫秒）

在scheduledExpirationRenewal方法里，其实就是用了netty的时间轮进行定时任务调度，每隔10秒重置锁时间为30秒，直到业务执行结束。

每次续期成功后，会递归调用 renewExpiration()，形成 无限续期链，直到锁被释放（主动释放或者客户端宕机）。

关于 时间轮，这是一种高效的定时任务调度设计。

感兴趣的朋友可以去看下之前写的文章：

时间轮：XXL-JOB 高效、精准定时任务调度实现思路分析_xxljob fasttriggerpool slowtrigger-CSDN博客

至于为什么不使用ScheduledThreadPoolExecutor？

是因为ScheduledThreadPoolExecutor的底层结构：基于优先级队列（堆实现）。插入任务的时间复杂度 O(log n)，每次插入需调整堆结构。

使用时间轮插入任务的时间复杂度为 O(1)，直接哈希到时间槽（Bucket），并且支持同一槽内任务批量触发。

3.5. Redisson怎么解决死锁的？

主要就是设置了锁的超时释放时间，客户端宕机了会自动超时释放。

然后还有一点支持重入，如果同一个线程两次去获取锁，因为支持重入，第二次就不会阻塞等待自己释放锁了。

至于说看门狗机制会无限续期，客户端宕机了就续期不了，不会导致死锁。

那你说：业务要是无限阻塞，永远执行不完呢？

这个也不大可能，为什么业务会无限阻塞？这个时候肯定需要人工介入去排查问题了。

今天的分享就到这里了，我是此林。

关注我吧，带你看不一样的世界！