Redisson 分布式锁源码 05:公平锁加锁

本文涉及的产品
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
简介: 默认的加锁逻辑是非公平的。在加锁失败时,线程会进入 while 循环,一直尝试获得锁,这时候是多线程进行竞争。就是说谁抢到就是谁的。

前言


默认的加锁逻辑是非公平的。

在加锁失败时,线程会进入 while 循环,一直尝试获得锁,这时候是多线程进行竞争。就是说谁抢到就是谁的。

Redisson 提供了 公平锁 机制,使用方式如下:

RLock fairLock = redisson.getFairLock("anyLock");
// 最常见的使用方法
fairLock.lock();
复制代码

下面一起看下公平锁是如何实现的?


公平锁

相信小伙伴们看过前面的文章,已经轻车熟路了,直接定位到源码方法:RedissonFairLock#tryLockInnerAsync

好家伙,这一大块代码,我截图也截不完,咱们直接分析 lua 脚本。

PS:虽然咱不懂 lua,但是这一堆堆的 if else 咱们大概还是能看懂的。

因为 debug 发现 command == RedisCommands.EVAL_LONG,所以直接看下面一部分。

网络异常,图片无法展示
|

这么长,连呼好几声好家伙!

先来看看参数都有啥?

  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 当前时间戳。

网络异常,图片无法展示
|

加锁队列和集合是含有大括号的字符串。{XXXX} 是指这个 key 仅使用 XXXX 用来计算 slot 的位置。


Lua 脚本分析

上面的 lua 脚本是分为几块的,咱们分别从不同的角度看下上面代码的执行。


首次加锁(Thread1)

网络异常,图片无法展示
|


第一部分,因为是首次加锁,所以等待队列为空,直接 跳出循环。这一部分执行结束。

网络异常,图片无法展示
|


第二部分:

  1. 当锁不存在,等待队列为空或队首是当前线程,两个条件都满足时,进入内部逻辑;
  2. 从等待队列和超时集合中删除当前线程,这时候等待队列和超时集合都是空的,不需要任何操作;
  3. 减少队列中所有等待线程的超时时间,也不需要任何操作;
  4. 加锁并设置超时时间。

执行完这里就 return 了。所以后面几部分就暂时不看了。

相当于下面两个命令(整个 lua 脚本都是原子的!):

> hset anyLock a3da2c83-b084-425c-a70f-5d9a08b37f31:1 1
> pexpire anyLock 30000
复制代码

网络异常,图片无法展示
|


Thread2 加锁

当 Thread1 加锁完成之后,此时 Thread2 来加锁。

Thread2 可以是本实例其他线程,也可以是其他实例的线程。

网络异常,图片无法展示
|


第一部分,虽然锁被 Thread1 占用了,但是等待队列是空的,直接跳出循环。

网络异常,图片无法展示
|


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

网络异常,图片无法展示
|


第三部分,线程是否持锁,没有持锁,直接跳过。


第四部分,线程是否在等待队列中,Thread2 才来加锁,不在里面,直接跳过。

网络异常,图片无法展示
|


Thread2 最后会来到这里:

  1. 从线程等待队列 redisson_lock_queue:{anyLock} 中获取最后一个线程;
  2. 因为等待队列是空的,所以直接获取当前锁的剩余时间 ttl anyLock
  3. 组装超时时间 timeout = ttl + 300000 + 当前时间戳,这个 300000 是默认 60000*5
  4. 使用 zadd 将 Thread2 放到等待线程有序集合,然后使用 rpush 将 Thread2 再放到等待队列中。

zadd KEYS[3] timeout ARGV[2]


这里使用 zadd 命令分别放置的是,redisson_lock_timeout:{anyLock},超时时间戳(1624612689520),线程(UUID2:Thread2)。

其中超时时间戳当分数,用来在有序集合中排序,表示加锁的顺序。

网络异常,图片无法展示
|


Thread3 加锁

网络异常,图片无法展示
|


Thread1 占有了锁,Thread2 在等待,此时线程 3 来了。

网络异常,图片无法展示
|

获取 firstThreadId2 此时队列是有线程的是 UUID2:Thread2。


判断 firstThreadId2 的分数(超时时间戳)是不是小于当前时间戳:

  1. 小于等于则说明超时了,移除 firstThreadId2;
  2. 大于,则会进入后续判断。

第二、三、四部分都不满足条件。

网络异常,图片无法展示
|


Thread3 最后也会来到这里:

  1. 从线程等待队列 redisson_lock_queue:{anyLock} 中获取最后一个线程;
  2. 最后一个线程存在,且不是自己,则 ttl = lastThreadId 超时时间戳 - 当前时间戳,就是看最后一个线程还有多久超时;
  3. 组装超时时间 timeout = ttl + 300000 + 当前时间戳,这个 300000 是默认 60000*5,在最后一个线程的超时时间上加上 300000 以及当前时间戳,就是 Thread3 的超时时间戳。
  4. 使用 zadd 将 Thread3 放到等待线程有序集合,然后使用 rpush 将 Thread3 再放到等待队列中。

网络异常,图片无法展示
|


总结


本文主要总结了公平锁的加锁逻辑,这涉及到比较多的 Redis 操作,做一下简要总结:

  1. Redis Hash 数据结构:存放当前锁,Redis Key 就是锁,Hash 的 field 是加锁线程,Hash 的 value 是 重入次数;
  2. Redis List 数据结构:充当线程等待队列,新的等待线程会使用 rpush 命令放在队列右边;
  3. Redis sorted set 有序集合数据结构:存放等待线程的顺序,分数 score 用来是等待线程的超时时间戳。

网络异常,图片无法展示
|

需要理解的就是这里会额外添加一个等待队列,以及有序集合。

对照着 Java 公平锁源码阅读,理解起来效果更好。

目录
相关文章
|
7月前
|
NoSQL 调度 Redis
分布式锁—3.Redisson的公平锁
Redisson公平锁(RedissonFairLock)是一种基于Redis实现的分布式锁,确保多个线程按申请顺序获取锁,从而实现公平性。其核心机制是通过队列和有序集合管理线程的排队顺序。加锁时,线程会进入队列并等待,锁释放后,队列中的第一个线程优先获取锁。RedissonFairLock支持可重入加锁,即同一线程多次加锁不会阻塞。新旧版本在排队机制上有所不同,新版本在5分钟后才会重排队列,而旧版本在5秒后就会重排。释放锁时,Redisson会移除队列中等待超时的线程,并通知下一个排队的线程获取锁。通过这种机制,RedissonFairLock确保了锁的公平性和顺序性。
|
3月前
|
NoSQL Java 调度
分布式锁与分布式锁使用 Redis 和 Spring Boot 进行调度锁(不带 ShedLock)
分布式锁是分布式系统中用于同步多节点访问共享资源的机制,防止并发操作带来的冲突。本文介绍了基于Spring Boot和Redis实现分布式锁的技术方案,涵盖锁的获取与释放、Redis配置、服务调度及多实例运行等内容,通过Docker Compose搭建环境,验证了锁的有效性与互斥特性。
217 0
分布式锁与分布式锁使用 Redis 和 Spring Boot 进行调度锁(不带 ShedLock)
|
5月前
|
NoSQL Java Redis
基于Redisson和自定义注解的分布式锁实现策略。
在实现分布式锁时,保证各个组件配置恰当、异常处理充足、资源清理彻底是至关重要的。这样保障了在分布布局场景下,锁的正确性和高效性,使得系统的稳健性得到增强。通过这种方式,可以有效预防并发环境下的资源冲突问题。
275 29
|
4月前
|
NoSQL Redis
分布式锁设计吗,你是如何实现锁类型切换、锁策略切换基于限流的?
本方案基于自定义注解与AOP实现分布式锁,支持锁类型(如可重入锁、公平锁等)与加锁策略(如重试、抛异常等)的灵活切换,并结合Redisson实现可重入、自动续期等功能,通过LUA脚本保障原子性,兼顾扩展性与实用性。
89 0
|
5月前
|
缓存 NoSQL Java
【📕分布式锁通关指南 11】源码剖析redisson之读写锁的实现
Redisson 的 `RedissonReadWriteLock` 提供了高效的分布式读写锁实现,适用于读多写少的场景。通过 Redis 与 Lua 脚本结合,确保读锁并行、写锁互斥,以及读写之间的互斥,保障了分布式环境下的数据一致性。它支持可重入、自动过期和锁释放机制,提升了系统并发性能与资源控制能力。
114 0
|
7月前
|
NoSQL 调度 Redis
分布式锁—5.Redisson的读写锁
Redisson读写锁(RedissonReadWriteLock)是Redisson提供的一种分布式锁机制,支持读锁和写锁的互斥与并发控制。读锁允许多个线程同时获取,适用于读多写少的场景,而写锁则是独占锁,确保写操作的互斥性。Redisson通过Lua脚本实现锁的获取、释放和重入逻辑,并利用WatchDog机制自动续期锁的过期时间,防止锁因超时被误释放。 读锁的获取逻辑通过Lua脚本实现,支持读读不互斥,即多个线程可以同时获取读锁。写锁的获取逻辑则确保写写互斥和读写互斥,即同一时间只能有一个线程获取写锁,
376 17
|
NoSQL 安全 调度
【📕分布式锁通关指南 10】源码剖析redisson之MultiLock的实现
Redisson 的 MultiLock 是一种分布式锁实现,支持对多个独立的 RLock 同时加锁或解锁。它通过“整锁整放”机制确保所有锁要么全部加锁成功,要么完全回滚,避免状态不一致。适用于跨多个 Redis 实例或节点的场景,如分布式任务调度。其核心逻辑基于遍历加锁列表,失败时自动释放已获取的锁,保证原子性。解锁时亦逐一操作,降低死锁风险。MultiLock 不依赖 Lua 脚本,而是封装多锁协调,满足高一致性需求的业务场景。
253 0
【📕分布式锁通关指南 10】源码剖析redisson之MultiLock的实现
|
7月前
|
算法 NoSQL Redis
分布式锁—4.Redisson的联锁和红锁
Redisson的MultiLock和RedLock机制为分布式锁提供了强大的支持。MultiLock允许一次性锁定多个资源,确保在更新这些资源时不会被其他线程干扰。它通过将多个锁合并为一个大锁,统一进行加锁和释放操作。RedissonMultiLock的实现通过遍历所有锁并尝试加锁,若在超时时间内无法获取所有锁,则释放已获取的锁并重试。 RedLock算法则基于多个Redis节点的加锁机制,确保在大多数节点上加锁成功即可。RedissonRedLock通过重载MultiLock的failedLocksLi
403 10
|
7月前
|
NoSQL Java Redis
分布式锁—6.Redisson的同步器组件
Redisson提供了多种分布式同步工具,包括分布式锁、Semaphore和CountDownLatch。分布式锁包括可重入锁、公平锁、联锁、红锁和读写锁,适用于不同的并发控制场景。Semaphore允许多个线程同时获取锁,适用于资源池管理。CountDownLatch则用于线程间的同步,确保一组线程完成操作后再继续执行。Redisson通过Redis实现这些同步机制,提供了高可用性和高性能的分布式同步解决方案。源码剖析部分详细介绍了这些组件的初始化和操作流程,展示了Redisson如何利用Redis命令和
|
7月前
|
监控 NoSQL Java
分布式锁—2.Redisson的可重入锁
本文主要介绍了Redisson可重入锁RedissonLock概述、可重入锁源码之创建RedissonClient实例、可重入锁源码之lua脚本加锁逻辑、可重入锁源码之WatchDog维持加锁逻辑、可重入锁源码之可重入加锁逻辑、可重入锁源码之锁的互斥阻塞逻辑、可重入锁源码之释放锁逻辑、可重入锁源码之获取锁超时与锁超时自动释放逻辑、可重入锁源码总结。