Redisson 分布式锁源码之一:可重入锁加锁

开发 后端 分布式 Redis
单系统很容易想到 Java 的各种锁,像 synchronize、ReentrantLock 等等等,那分布式系统如何处理?当然是使用分布式锁。

[[407548]]

前言

相信小伙伴都是使用分布式服务,那一定绕不开分布式服务中数据并发更新问题!

单系统很容易想到 Java 的各种锁,像 synchronize、ReentrantLock 等等等,那分布式系统如何处理?

当然是使用分布式锁。

如果小伙伴不知道什么是分布式锁,那推荐看看石杉老师的突击课或者在网上搜一搜相关资料。

当使用 Redis 作为分布式锁时,当前使用较多的框架就是 Redisson。

当然 Redisson 也不仅仅只能当做锁来使用,也有很多其他的功能,小伙伴们可以看一看官方文档,自己多动手实践一下。

下面就开始记录 Redisson 的相关笔记!错误之处,欢迎指正。

1、环境配置

  • 本地环境搭建的伪集群:

  • redisson 3.15.6

不同版本可能会有所不同,但是核心思想不会发生太大变化,如果变化很大,希望可以留言。

  1. <dependency> 
  2.     <groupId>org.redisson</groupId> 
  3.     <artifactId>redisson</artifactId> 
  4.     <version>3.15.6</version> 
  5. </dependency> 

 

  • 项目准备

一个简单的 maven 项目,只需要一个 Main 方法即可。

2、可重入锁加锁

在 lock.lock() 断点,作为源码入口。

默认加锁,什么参数也没有传递。但是这里会设置 leaseTime = -1。这个 leaseTime 的含义是加锁的时间。

剩下的一路挺进即可。

在调用 tryAcquire 方法之前,多了一个参数 threadId,是当前线程的 id,long 型正数。

异步加锁

直接来到 tryAcquireAsync 异步加锁方法。

tryAcquireAsync

前面已经说了 leaseTime 是 -1,所以这里会走到下面的方法中。

至此几个参数已经清楚:

  1. waitTime:-1;
  2. internalLockLeaseTime:使用默认时间 30000 毫秒;
  3. TimeUnit.MILLISECONDS:单位毫秒;
  4. threadId:线程 id;
  5. RedisCommands.EVAL_LONG:eval。

Redis eval 命令的相关文档可以阅读:https://redis.io/commands/eval

加锁逻辑

真正的加锁,其实就是这么一段 lua 脚本。

先说明一下 lua 脚本的参数信息:

  1. KEYS[1]:getRawName(),加锁的 key ,比如 anyLock;
  2. ARGV[1]:unit.toMillis(leaseTime),锁的毫秒时间,比如 30000;
  3. ARGV[2]:getLockName(threadId),是 UUID 和线程 id 拼接起来的字符串,比如 931573de-903e-42fd-baa7-428ebb7eda80:1。

因为使用的是 lua 脚本,可以保证这一块 lua 脚本的原子性。

首次加锁分析:

  1. exists 命令判断 redis anyLock 是否存在;
  2. 不存在,使用 hincrby 命令,创建 anyLock 数据;
  3. 对 anyLock 设置过期时间。

加锁后 Redis 内的数据格式是:

关于 Redis 的 Hash 数据结构可以阅读:https://redis.io/topics/data-types#hashes

抽象一点可以理解为 anyLock 下面挂着一个 K-V 结构的数据:

  1. "anyLock":{ 
  2.     "f400aad5-4b1f-4246-a81e-80c2717c3afb:1":"1" 

执行脚本

后续的内容就是进行请求执行 lua 脚本,唯一需要注意的地方就是有个哈希槽路由。

这块代码是在 CommandAsyncService#evalWriteAsync 方法处调用的,是为了获取一个 NodeSource。

当然这个 NodeSource 里面只存放了一个 slot(哈希槽值)。

这个 slot 值是对加锁的 key 使用 CRC16 算法计算出来的。

  1. // MAX_SLOT 默认 16384 
  2. int result = CRC16.crc16(key.getBytes()) % MAX_SLOT; 

这块计算一个 slot 到底有什么用呢?

继续追踪!

BaseRedisBatchExecutor#addBatchCommandData 在这里会从 source 里面获取到 solt,然后获得 MasterSlaveEntry。

大概可以理解为这里是获取到这个 Redis key 对应的节点。

可重入

既然是可重入锁,这块是支持可重入的,来看下可重入是如何保证的。

  1. exists 命令判断 redis key field 是否存在;
  2. 存在 则通过 hincrby 命令对 key 的 field 对应 value 自增;
  3. 为当前 redis key 设置过期时间。

加锁互斥

上面已经验证了两种情况:

  1. redis key 不存在;
  2. redis key 和 key 的 field 存在。

剩下的情况就是 key 存在的情况下,但是 field 不存在。

要知道 key 的 field 放的是 UUID:ThreadId,说明加锁的不是当前线程。这时候直接返回当前锁的剩余时间。

3、总结

本文主要介绍了 Redisson 可重入锁的加锁、锁重入、锁互斥逻辑。

核心重点在 lua 脚本。同时需要理解 Redis 的 Hash 数据结构。

同时需要记住,在未指定加锁时间时,默认使用的是 30s。

最后,一张图介绍本文加锁逻辑。

 

 

责任编辑:武晓燕 来源: 程序员小航
相关推荐

2021-07-08 09:21:17

ZooKeeper分布式锁 Curator

2021-06-30 14:56:12

Redisson分布式公平锁

2021-07-10 10:02:30

ZooKeeperCurator并发

2021-07-01 09:42:08

Redisson分布式

2021-07-09 06:48:31

ZooKeeperCurator源码

2021-07-03 17:45:57

分布式Redisson MultiLock

2021-07-06 08:37:29

Redisson分布式

2021-07-02 08:51:09

Redisson分布式锁公平锁

2022-08-04 08:45:50

Redisson分布式锁工具

2021-07-07 07:09:49

Redisson分布式锁源码

2022-06-30 08:04:16

Redis分布式锁Redisson

2020-06-15 08:15:47

分布式锁系统

2021-06-28 10:51:55

Redisson分布式锁Watchdog

2024-01-02 13:15:00

分布式锁RedissonRedis

2021-07-16 07:57:34

ZooKeeperCurator源码

2024-01-30 08:41:33

线程执行Redis分布式锁

2023-08-27 22:13:59

Redisson分布式缓存

2021-09-17 07:51:24

RedissonRedis分布式

2018-11-27 16:17:13

分布式Tomcat

2021-11-26 06:43:19

Java分布式
点赞
收藏

51CTO技术栈公众号