Redisson分布式锁案列和源码解读

发布于:2025-05-22 ⋅ 阅读:(18) ⋅ 点赞:(0)

分布式锁的核心功能其实就三个:加锁、解锁、设置锁超时

同时在了解分布式锁之前,也需要了解Redis的发布订阅功能。

Redis的发布订阅功能

具体的操作演示如下:

         开启3个客户端,一个订阅了频道 **channel1** ,另外个订阅了频道 **channel1**,最后一个通过PUBLISH发送消息后,订阅的那个就能收到了,靠这种模式就能实现不同客户端之间的通信。 

Redisson分布式锁源码整体分析

RLock接口

       **RLock**是一个接口,具体的同步器需要实现该接口,当我们调用 `redisson.getLock()`时,程序会初始化一个默认的同步执行器**RedissonLock** 

1、commandExecutor :异步的Executor执行器,Redisson中所有的命令都是通过...Executor 执行的 ;

2、internalLockLeaseTime:等待获取锁时间,这里读的是配置类中默认定义的,时间为30秒;

3、pubSub:封装了发布订阅功能组件

 Redisson锁的执行流程

通过Redis的monitor监控Redis服务器的命令 

 1、不启动看门狗的加锁

这里只加锁,然后让主线程休眠,我们看下针对Redis做了什么操作

这里可以和《Redisson锁的执行流程》对应看一看。

这里可以看到Redisson的加锁实际上是一个Lua脚本+针对一个哈希类型的操作(hincrby命令)

2、不启动看门狗的加锁+解锁

这里可以看到:

这里可以看到Redisson的解锁实际上是一个Lua脚本(del操作)+publish发布的操作。

3、不启动看门狗的加锁+解锁(重入锁的情况)

 可以看到这里没有删除掉key,这里实现锁的可重入是利用一个计数,加锁一次就加1,解锁一次就减1。

4、启动看门狗的加锁 

 Redisson锁的执行流程+源码分析

跟踪lock方法进入源码

代码还是挺长的,不过流程也就两步:

**要么线程拿到锁返回成功;**

**要么没拿到锁并且等待时间还没过就继续循环拿锁(这里使用监听机制避免来优化了),同时监听锁是否被释放。**

以上的Lua脚本就比较清晰了:

1、当前key不存在:标识锁未被占用

2、使用hset写入一个hash类型的数据:其中,key为锁的名称、field为“Redisson客户端ID:线程id”,value=1

3、执行pexpire,设置失效时间

4、当前key存在:标识已经获取到了锁

5、hincrby新增field的value,并且重新设置超时时间。

6、最后都不满足:获取锁失败,返回锁的剩余超时时间。

**拿不到的话,就会返回锁的剩余过期时长,这个时长有什么作用呢???**

用Java的Semaphore信号量的tryAcquire方法来阻塞线程。

Semaphore信号量又是由谁控制呢,何时才能release呢。

这段代码的作用在于将当前线程的**threadId**添加到一个**AsyncSemaphore**中,并且设置一个redis的监听器,这个监听器是通过redis的发布、订阅功能实现的。

一旦监听器收到redis发来的消息,就从中获取与当前thread相关的,如果是锁被释放的消息,就立马通过操作 **Semaphore** (也就是调用**release**方法)来让刚才阻塞的地方释放。

看门狗线程续锁

io.netty.util.Timeout 使用

这个源码,就是一个定时器,每隔 10s 递归执行一次


网站公告

今日签到

点亮在社区的每一天
去签到