Redisson分布式锁源码之公平锁排队加锁

Redisson 分布式锁源码之公平锁排队加锁

作者:程序员小航 2021-07-01 09:42:08

前端
分布式
Redis Redis sorted set 有序集合数据结构:存放等待线程的顺序,分数 score 用来是等待线程的超时时间戳。

创新互联建站成立10余年来,这条路我们正越走越好,积累了技术与客户资源,形成了良好的口碑。为客户提供成都做网站、成都网站设计、网站策划、网页设计、国际域名空间、网络营销、VI设计、网站改版、漏洞修补等服务。网站是否美观、功能强大、用户体验好、性价比高、打开快等等,这些对于网站建设都非常重要,创新互联建站通过对建站技术性的掌握、对创意设计的研究为客户提供一站式互联网解决方案,携手广大客户,共同发展进步。

前言

在上一篇文章中已经分析过公平锁的加锁源码,并得出结论:

Redis Hash 数据结构:存放当前锁,Redis Key 就是锁,Hash 的 field 是加锁线程,Hash 的 value 是 重入次数;

Redis List 数据结构:充当线程等待队列,新的等待线程会使用 rpush 命令放在队列右边;

Redis sorted set 有序集合数据结构:存放等待线程的顺序,分数 score 用来是等待线程的超时时间戳。

现在看一下加锁失败被放到等待队列之后,线程是如何处理的?

1排队等锁

源码入口:org.redisson.RedissonLock#lock(long, java.util.concurrent.TimeUnit, boolean)。

线程进入排队之后,在 Java 代码中会 while (true) 一直循环调用 tryAcquire,尝试获取锁。

最终还是来到 RedissonFairLock#tryLockInnerAsync 方法中。

方便起见,重新贴一下 Lua 脚本,以及脚本的参数含义。

  1. KEYS[1]:加锁的名字,anyLock;
  2. KEYS[2]:加锁等待队列,redisson_lock_queue:{anyLock};
  3. KEYS[3]:等待队列中线程锁时间的 set 集合,redisson_lock_timeout:{anyLock},是按照锁的时间戳存放到集合中的;
  4. ARGV[1]:锁超时时间 30000
  5. ARGV[2]:UUID:ThreadId 组合 a3da2c83-b084-425c-a70f-5d9a08b37f31:1
  6. ARGV[3]:threadWaitTime 默认 300000
  7. ARGV[4]:currentTime 当前时间戳

源码分析

第一部分,while 循环:

  1. 从等待队列 redisson_lock_queue:{anyLock} 中获取第一个等待线程;
  2. 从等待线程超时集合 redisson_lock_timeout:{anyLock} 中获取第一个等待线程的分数;
  3. 没有超时,直接结束,超时了,则直接移除。

第二部分,当前锁存在,直接跳过。

第三部分,当前锁不是持锁线程,直接跳过。

第四部分,

直接返回当前锁还有多久到期。

当前 Redisson 版本为 3.15.6,不同版本的略有不同。

队列重排

这里不存在重新排序,因为官方认为这是一个 bug,重新进行了修复。

具体可以阅读:Justin Corpron 2019/5/10, 04:13 Fix timeout drift in RedissonFairLock

最大的变化就是增加了第四部分。

图仅仅代表两个版本的差别,并不是代表这个版本才修改。

2总结

当线程获取锁失败,进入到等待队列时,ttl != null,在 Java 代码中会不断尝试获取锁。

当锁不存在且当前线程是在等待队列头时,直接获得锁。这个排队的过程就是公平锁的提现。

本文转载自微信公众号「程序员小航」,可以通过以下二维码关注。转载本文请联系程序员小航公众号。

网页名称:Redisson分布式锁源码之公平锁排队加锁
文章地址:http://www.shufengxianlan.com/qtweb/news35/255485.html

网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等

广告

声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联