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

前言

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

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

当然是使用分布式锁。

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

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

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

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

环境配置#

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

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

<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson</artifactId>
    <version>3.15.6</version>
</dependency>

  • 项目准备

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

可重入锁加锁#

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


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

剩下的一路挺进即可。

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

异步加锁#

直接来到 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 结构的数据:

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

执行脚本#

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

可重入#

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

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

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

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

继续追踪!

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

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

可重入#

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

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

加锁互斥#

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

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

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

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

总结#

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

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

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

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

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,772评论 6 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,458评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,610评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,640评论 1 276
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,657评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,590评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,962评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,631评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,870评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,611评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,704评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,386评论 4 319
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,969评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,944评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,179评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 44,742评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,440评论 2 342

推荐阅读更多精彩内容