Redisson分布锁原理分析及源码解读

我不是女神ヾ 2023-09-23 16:12 105阅读 0赞

> **本文源码解读基于Redisson 3.18.0 版本**

## Redisson分布锁实现原理 ##

Redisson锁实现基本原理大致如下图所示：

![format_png][]

> 客户端执行Lua脚本去获取锁，如果获取失败，则订阅解锁消息，并挂起线程。
> 
> 客户端解锁时执行一段Lua脚本，删除锁的同时往解锁消息通道发送解锁指令，Redis会广播解锁消息到所有订阅的客户端。
> 
> 当客户端收到解锁消息或者线程挂起时间超过锁超时时间(leaseTime)时，客户端会重新尝试获取分布式锁，如果仍然获不到，则线程再度进入阻塞状态，等待解锁消息到达或者锁超时。
> 
> 如果等待时间超出了最大可等待时间(waitTime)，会直接返回锁获取失败。
> 
> 无论成功还是失败，当前客户端线程最后都会取消订阅解锁消息。

## Redisson客户端加锁流程 ##

### 1.尝试获取分布式锁 ###

以tryLock(long waitTime, long leaseTime, TimeUnit unit)方法为例：

*  waitTime 获取锁时最大等待时间
 *  leaseTime 获得锁后，设置的锁超时时间

tryLock方法为尝试获取锁的方法入口，返回ttl表示锁剩余超时时间，如果返回null，表示无人占有锁，当前线程获取锁成功,如果获取锁成功，客户端会启动一个看门狗线程，来自动为锁续期(后面会讲到看门狗作用)。tryLock方法过程时序图如下：

![format_png 1][]

核心为图中红色部份的tryLockInnerAsync方法,他通过evalWriteAsync执行了一段lua脚本如下.

*  KEYS\[1\]：锁名称
 *  ARGV\[1\]：锁过期时间
 *  ARGV\[2\]：客户端唯一标识(Client UUID+threadId).

# 如果锁不存在 
    if (redis.call('exists', KEYS[1]) == 0) then
        # hash结构,锁名称为key,线程唯一标识为itemKey，itemValue为一个计数器。支持相同客户端线程可重入,每次加锁计数器+1.
        redis.call('hincrby', KEYS[1], ARGV[2], 1);
        # 设置过期时间
        redis.call('pexpire', KEYS[1], ARGV[1]);
        # 成功获取锁返回null
        return nil;
    end ;
    #如果是当前线程占有分布式锁，允许重入锁
    if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then
        # 将锁重入计数器自增1.
        redis.call('hincrby', KEYS[1], ARGV[2], 1);
        # 设置过期时间
        redis.call('pexpire', KEYS[1], ARGV[1]);
        # 成功获取锁返回null
        return nil;
    end ;
    #如果获取不到锁，返回锁剩余过期时间
    return redis.call('pttl', KEYS[1]);
    复制代码

### 2.获取锁失败，订阅解锁消息channel ###

图1处：判断获取锁是否等待(waitTime)超时，如果等待超时则直接返回获取锁失败。

图2处：如果等待未超时，则尝试订阅解锁channel。

图3处：获取ReissonLockEntry(获取成功表示订阅成功)，超时时长设置为当前剩余的等待时间(waitTime)。 如果获取ReissonLockEntry超时，终止并取消解锁消息channel订阅，获取锁失败。

![format_png 2][]

### 3.收到解锁通知，重新竞争锁 ###

此处的代码紧接上面，因为图片太大故切成两块了：

![format_png 3][]

这里主要分析红色圆圈处的while代码块。这里的while代码是一个循环尝试，直到获取锁成功或者超时失败。 解锁消息是广播给所有锁竞争的客户端的，收到解锁消息后，所有的客户端进程都会有一个线程去重新竞争锁。

![format_png 4][]

图1处：和第一步获取锁的代码一模一样，尝试执行lua脚本获取锁

图2处：此处使用信号量处理**一个客户端进程中有多个线程**竞争分布式锁的场景。

当有解锁消息到达时，不需要所有挂起线程都恢复，一起去竞争分布式锁，只需要唤醒一个线程去抢夺就可以了。Redisson使用信号量控制，每次收到解锁消息仅释放一个信号，只允许一个线程解除阻塞状态，去竞争锁(参考LockPubSub类的onMessage方法)，当然，如果线程等待超时(超过锁过期时间)也会重新加入锁竞争行列。

![format_png 5][]

由此代码分析可知，即时解锁消息通知失败。客户端也能在锁超时后重新尝试获取锁。实际上在比较旧一些的版本(3.13.1之前,参考 [github.com/redisson/re…][github.com_redisson_re] )中,如果解锁消息因为网络原因而丢失，客户端总会因等待超时而失败。

## Redisson客户端解锁流程 ##

解锁代码比较简单，其核心逻辑在RedissonLock.unlockInnerAsync(long threadId)方法里

![format_png 6][]

unlockInnerAsync方法lua脚本代码说明如下：

*  KEYS\[1\]：锁名称
 *  KEYS\[2\]：解锁消息通道名称
 *  ARGV\[1\]：解锁消息
 *  ARGV\[2\]：锁续租时间(看门狗超时时间，默认为30秒)
 *  ARGV\[3\]：客户端唯一标识

# 判断锁是否为自己持有，不为自己持有则不允许解锁。
    if (redis.call('hexists', KEYS[1], ARGV[3]) == 0) then
        return nil;
    end ;
    # 由于支持可重入，所以这里需要判断是否完全解锁，每解一次锁重入计数器减1.
    local counter = redis.call('hincrby', KEYS[1], ARGV[3], -1);
    if (counter > 0) then
        # 如果锁还没有完全解除，则延长锁租用时间
        redis.call('pexpire', KEYS[1], ARGV[2]);
        return 0;
    else
        # 删除锁
        redis.call('del', KEYS[1]);
        # 广播解锁消息
        redis.call('publish', KEYS[2], ARGV[1]);
        return 1;
    end ;
    return nil;
    复制代码

## Redisson看门狗机制 ##

如果锁中的业务处理时间比较长，那么可能一种异常情况：即业务还未处理完毕，锁就提前过期了。Redisson针对这个问题的解决办法，是提供一个守护线程，定时检查锁状态。如果锁快要过期了，客户端还占有锁，那么就自动给锁续期，延长锁的过期时间。

![format_png 7][]

守护线程轮询周期为：internalLockLeaseTime/3。internalLockLeaseTime的默认值由lockWatchdogTimeout来配置。默认值为30秒。也就是说默认情况下，守护线程每10秒检查续期。

![format_png 8][]

续期靠执行下面这段lua脚本实现，每次续期时间由lockWatchdogTimeout配置项决定，默认30秒。

![format_png 9][]

## 无PubSub锁-RedissonSpinLock ##

由于Redis PubSub的不可靠性，消息丢失几率是相对较高的。所以在RedissonLock的实现中，客户端等待解锁消息时都会设置超时时间，一旦超时客户端线程也会解除阻塞状态，重新进入锁竞争状态。

其实仔细想想，这里即使没有PubSub，锁的获取通过不断的自旋(重试)一样可以保证分布式锁的可靠性。只不过如果每次阻塞挂起的时间都设置为锁超时时间，会影响性能，因为大多数场景下业务处理时间要远远快于锁的超时时间。那么我们能不能考虑像RocketMQ消费者重试机制一样，一开始重试间隔时间很短，后续逐步增加重试间隔了？

其实官方已经有了对应的实现了，它就是RedissonSpinLock。来看看RedissonSpinLock是如何实现加锁的。

![format_png 10][]

这代码看着可清爽多了...

RedissonSpinLock的核心就是红框处的代码，每次自旋竞争锁前先休眠一段时间，这个时间间隔由LockOptions.BackOffPolicy来指定。

官方目前提供了两种BackOffPolicy的实现：

*  **ConstantBackOffPolicy** 指定一个常量间隔，每次自旋休眠固定时长
 *  **ExponentialBackOffPolicy**

![format_png 11][]

每次按倍数multiplier增长，同时加个失败次数fails为种子的随机整数。最大值不能超过指定值-maxDelay 默认值：

*  initialDelay=1
 *  multiplier = 2
 *  maxDelay = 128

不要觉得自旋多重试了几次就会对性能有多大影响，要知道Redis每秒QPS可是能达到10W+级别的，区区几次重试完全可以忽略不计。不信可以瞅瞅官方的基准测试 [redis.io/docs/manage…][redis.io_docs_manage]

## 关于红锁 ##

有一种极端场景，客户端A尝试在Redis Master节点上锁，客户端A成功获得锁的瞬间，锁数据还没有同步至Slave节点。这时Master挂了，于是发生主从切换，其它客户端连接到Slave节点尝试抢占锁，由于Slave没有客户端A的上锁信息。自然又会有一个新的客户端B抢到锁，此时就会出现两个客户端同时拥有分布式锁的奇葩现像。

针对上述问题，Redis作者曾经提出了Redlock方案。Redisson中也有相应的实现，不过现在最新的版本已经不再建议使用。

![format_png 12][]

因为现在基础的加锁操作，会广播到所有从节点，等所有从节点同步了才算加锁成功。

参考CommandBatchService.executeAsync方法代码，底层实现是通过Redis Wait命令，实现Master-Slave同步复制。

![format_png 13][]

[format_png]: https://img-blog.csdnimg.cn/img_convert/86c1c2d27d167e583f7f0f2023c63e91.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/a534b17bb7e5dbbebe87f22b7ec6ee81.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/7f0ea78903396c5048977098a2931e65.webp?x-oss-process=image/format,png
[format_png 3]: https://img-blog.csdnimg.cn/img_convert/5d838e09aa6ae69cd30634ea0812bbc0.webp?x-oss-process=image/format,png
[format_png 4]: https://img-blog.csdnimg.cn/img_convert/e210043eebcbdbc9f6234583c082b3cd.webp?x-oss-process=image/format,png
[format_png 5]: https://img-blog.csdnimg.cn/img_convert/d558b0aa9681968f83e4ffbb389fbdd2.webp?x-oss-process=image/format,png
[github.com_redisson_re]: https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2Fredisson%2Fredisson%2Fissues%2F3067
[format_png 6]: https://img-blog.csdnimg.cn/img_convert/2843f1382f258d6fa577823d22d7766d.webp?x-oss-process=image/format,png
[format_png 7]: https://img-blog.csdnimg.cn/img_convert/5212326a35d60d806eade933aa2e3823.webp?x-oss-process=image/format,png
[format_png 8]: https://img-blog.csdnimg.cn/img_convert/95ea8829524ab8c72a748243a97a6cdb.webp?x-oss-process=image/format,png
[format_png 9]: https://img-blog.csdnimg.cn/img_convert/cb48691657cf331eb41c256ae160a116.webp?x-oss-process=image/format,png
[format_png 10]: https://img-blog.csdnimg.cn/img_convert/a8503764d27ae6e41d78cc30517fffda.webp?x-oss-process=image/format,png
[format_png 11]: https://img-blog.csdnimg.cn/img_convert/6fea4684027fb6914c0163c15c6f76e5.webp?x-oss-process=image/format,png
[redis.io_docs_manage]: https://link.juejin.cn?target=https%3A%2F%2Fredis.io%2Fdocs%2Fmanagement%2Foptimization%2Fbenchmarks%2F
[format_png 12]: https://img-blog.csdnimg.cn/img_convert/afe9cd6c5cace23bb28d33082cfeff90.webp?x-oss-process=image/format,png
[format_png 13]: https://img-blog.csdnimg.cn/img_convert/c27aaed33bd7a90322a4e7cb27972aaa.webp?x-oss-process=image/format,png