Redis分布式锁实现Redisson 15问(一)

发布于 2022-6-17 16:57
浏览
0收藏

 

Redis分布式锁实现Redisson 15问(一)-开源基础软件社区

大家好,我是三友。

 

在一个分布式系统中,由于涉及到多个实例同时对同一个资源加锁的问题,像传统的synchronized、ReentrantLock等单进程情况加锁的api就不再适用,需要使用分布式锁来保证多服务实例之间加锁的安全性。常见的分布式锁的实现方式有zookeeper和redis等。而由于redis分布式锁相对于比较简单,在实际的项目中,redis分布式锁被用于很多实际的业务场景中。

 

redis分布式锁的实现中又以Redisson比较出名,所以本文来着重看一下Redisson是如何实现分布式锁的,以及Redisson提供了哪些其它的功能。

 

一、如何保证加锁的原子性

 

说到redis的分布式锁,可能第一时间就想到了setNx命令,这个命令保证一个key同时只能有一个线程设置成功,这样就能实现加锁的互斥性。但是Redisson并没有通过setNx命令来实现加锁,而是自己实现了一套完成的加锁的逻辑。

 

Redisson的加锁使用代码如下,接下来会有几节着重分析一下这段代码逻辑背后实现的原理。

Redis分布式锁实现Redisson 15问(一)-开源基础软件社区

先通过RedissonClient,传入锁的名称,拿到一个RLock,然后通过RLock实现加锁和释放锁。

Redis分布式锁实现Redisson 15问(一)-开源基础软件社区

getLock获得的RLock接口的实现是RedissonLock,所以我们看一下RedissonLock对lock()方法的实现。

Redis分布式锁实现Redisson 15问(一)-开源基础软件社区

lock方法会调用重载的lock方法,传入的leaseTime为-1,调用到这个lock方法,之后会调用tryAcquire实现加锁的逻辑。

Redis分布式锁实现Redisson 15问(一)-开源基础软件社区

tryAcquire最后会调到tryAcquireAsync方法,传入了leaseTime和当前加锁线程的id。tryAcquire和tryAcquireAsync的区别就是tryAcquireAsync是异步执行,而tryAcquire是同步等待tryAcquireAsync的结果,也就是异步转同步的过程。

Redis分布式锁实现Redisson 15问(一)-开源基础软件社区

tryAcquireAsync方法会根据leaseTime是不是-1来判断使用哪个分支加锁,其实不论走哪个分支,最后都是调用tryLockInnerAsync方法来实现加锁,只不过是参数不同罢了。但是我们这里的leaseTime其实就是-1,所以会走下面的分支,尽管传入到tryAcquireAsync的leaseTime是-1,但是在调用tryLockInnerAsync方法传入的leaseTime参数是internalLockLeaseTime,默认是30s。

 

tryLockInnerAsync方法。

Redis分布式锁实现Redisson 15问(一)-开源基础软件社区

通过tryLockInnerAsync方法的实现可以看出,最终加锁是通过一段lua脚本来实现加锁的,redis在执行lua脚本的时候是可以保证加锁的原子性的,所以Redisson实现加锁的原子性是依赖lua脚本来实现的。其实对于RedissonLock这个实现来说,最终实现加锁的逻辑都是通过tryLockInnerAsync来实现的。

 

来一张图总结一下lock方法加锁的调用逻辑。

Redis分布式锁实现Redisson 15问(一)-开源基础软件社区

二、如何通过lua脚本实现加锁

 

通过上面分析可以看出,redis是通过执行lua脚本来实现加锁,保证加锁的原子性。那么接下来分析一下这段lua脚本干了什么。

Redis分布式锁实现Redisson 15问(一)-开源基础软件社区

其中这段脚本中的lua脚本中的参数的意思:

  • KEYS[1]:就是锁的名称,对于我们的demo来说,就是myLock
  • ARGV[1]:就是锁的过期时间,不指定的话默认是30s
  • ARGV[2]:代表了加锁的唯一标识,由UUID和线程id组成。一个Redisson客户端一个UUID,UUID代表了一个唯一的客户端。所以由UUID和线程id组成了加锁的唯一标识,可以理解为某个客户端的某个线程加锁。

 

那么这些参数是怎么传过去的呢,其实是在这里。

Redis分布式锁实现Redisson 15问(一)-开源基础软件社区

  • getName:方法就是获取锁的名称
  • leaseTime:就是传入的锁的过期时间,如果指定超时时间就是指定的时间,没指定默认是30s
  • getLockName:就是获取加锁的客户端线程的唯一标识。

 

分析一下这段lua的加锁的逻辑。

 

1)先调用redis的exists命令判断加锁的key存不存在,如果不存在的话,那么就进入if。不存在的意思就是还没有某个客户端的某个线程来加锁,第一次加锁肯定没有人来加锁,于是第一次if条件成立。

 

2)然后调用redis的hincrby的命令,设置加锁的key和加锁的某个客户端的某个线程,加锁次数设置为1,加锁次数很关键,是实现可重入锁特性的一个关键数据。用hash数据结构保存。hincrby命令完成后就形成如下的数据结构。

 

myLock:{

"b983c153-7421-469a-addb-44fb92259a1b:1":1


}

 

3)最后调用redis的pexpire的命令,将加锁的key过期时间设置为30s。

 

从这里可以看出,第一次有某个客户端的某个线程来加锁的逻辑还是挺简单的,就是判断有没有人加过锁,没有的话就自己去加锁,设置加锁的key,再存一下加锁的线程和加锁次数,设置一下锁的过期时间为30s。

 

画一张图来看一下lua脚本加锁的逻辑干了什么。

Redis分布式锁实现Redisson 15问(一)-开源基础软件社区

至于第二段if是干什么的,我们后面再说。

 

文章转自公众号:三友的java日记

标签
已于2022-6-17 16:57:25修改
收藏
回复
举报
回复
添加资源
添加资源将有机会获得更多曝光,你也可以直接关联已上传资源 去关联
    相关推荐