当前位置: 首页 > news >正文

【分布式锁通关指南 09】源码剖析redisson之公平锁的实现

引言

在本篇中,我们继续探索redisson中相关锁的实现,本期将围绕公平锁进行讲解。在正式开始前,我们回顾下公平锁的概念-在多线程或分布式环境中,锁的获取是有先后顺序的,按照请求顺序来获得锁。这就意味着A、B、C 三个线程都想获得同一把锁,那么最先请求的线程会被优先给予资源。如果此时锁被某个线程占用,其余线程会根据各自的排队顺序来抢占锁,谁排在前面,谁就先获得锁。

在 Redisson 中,对分布式 Redis 锁的公平性,就是说锁的获取需要按照先来后到排队,避免后来的请求“插队”。

加锁

我们先来看看如何实现加锁的,在 RedissonFairLock 类里,我们可以找到核心加锁逻辑:

public void lock() {try {// 1. 尝试获取锁if (tryAcquire()) {return;}// 2. 获取失败,将当前线程信息写入等待队列long threadId = Thread.currentThread().getId();Long ttl = tryAcquisition(threadId);// 3. 循环等待获取锁while (ttl != null) {// 订阅锁释放消息subscribe(threadId);// 等待锁释放通知await(ttl);// 重试获取锁ttl = tryAcquisition(threadId);}} finally {// 取消订阅unsubscribe(Thread.currentThread().getId());}
}

可以看到调用tryAcquisition方法来尝试获取锁,这个方法里则封装了相关的Lua脚本,如下:

private Long tryAcquisition(long threadId) {return redis.eval("""-- 检查锁是否已被占用if (redis.call('exists', KEYS[1]) == 0) then-- 获取锁并设置threadIdredis.call('hset', KEYS[1], ARGV[2], 1);redis.call('pexpire', KEYS[1], ARGV[1]);-- 将线程加入等待队列末尾redis.call('zadd', KEYS[2], ARGV[3], ARGV[2]);return nil;end;-- 检查是否是队列第一个等待者local firstThreadId = redis.call('zrange', KEYS[2], 0, 0);if (firstThreadId[1] == ARGV[2]) then-- 获取锁redis.call('hset', KEYS[1], ARGV[2], 1);redis.call('pexpire', KEYS[1], ARGV[1]);-- 从等待队列移除redis.call('zrem', KEYS[2], ARGV[2]);return nil;end;-- 返回需要等待的时间return redis.call('pttl', KEYS[1]);""");

在尝试获取锁时:首先尝试直接获取锁;如果获取失败,将线程信息加入等待队列;只有当前线程是等待队列的第一个时才能获取锁;获取失败则订阅锁释放消息并等待;等待后重试获取锁,直到成功。

释放锁

看完了加锁,我们继续看释放锁,释放锁的核心逻辑在于Lua脚本的实现:

public void unlock() {redis.eval("""-- 检查是否是锁持有者if (redis.call('hexists', KEYS[1], ARGV[2]) == 0) thenreturn nil;end;-- 减少重入计数local counter = redis.call('hincrby', KEYS[1], ARGV[2], -1);if (counter > 0) thenredis.call('pexpire', KEYS[1], ARGV[1]);return 0;end;-- 删除锁redis.call('del', KEYS[1]);-- 发布释放消息redis.call('publish', KEYS[2], ARGV[2]);return 1;""");

解锁过程:验证当前线程是否是锁的持有者;处理重入计数的递减;当计数为0时完全释放锁;发布锁释放消息通知等待线程。

为何能保障“公平”?

1.先排队

Redisson 在请求 lock 时,会先把线程标识以一定的 score(通常是时间戳)存储进 ZSet。这样就等于“先到先排队”。

2.只允许队首“抢”锁

脚本会检查 ZSet 的首位元素(ZRANGE KEYS[2], 0, 0),只有首位(rank == 0)的线程才有真正“尝试加锁”的资格。

3.不可插队

因为 Lua 脚本在 Redis 里是原子执行的,不会出现其他线程“并发修改队列”的情况,且 ZSet 的 score 是根据时间先后确定顺序。不会让后来的线程“插队”。

4.线程之间实时通知

当锁释放后,publish 通知所有订阅方,后面排队的线程就能及时知道“锁可以重新争抢了”,然后再调用加锁脚本进行排名检查,最终实现“先来先拿”。

小结

通过这些 Lua 脚本的实现逻辑,相信各位读者已经理解了 Redisson 公平锁为什么能做到“先来先得”,以及其在分布式环境下是如何保证线程安全、互不干扰的。还是那句话,看源码的目的在于学习别人优秀的设计,希望对大家有所启发!

相关文章:

  • [KVM] KVM挂起状态恢复失败与KVM存储池迁移
  • Spring JDBC 的开发步骤(注解方式)
  • 私有知识库 Coco AI 实战(三):摄入 Elasticsearch 官方文档
  • Go语言学习笔记(一)
  • 【论文阅读】Dual-branch Cross-Patch Attention Learning for Group Affect Recognition
  • 代理模式:控制对象访问的中间层设计
  • 论文阅读 | 大模型工具调用控制的策略优化
  • Spark与Hadoop之间的联系与区别
  • 使用nodeJs的express+axios+cors做代理
  • 配置MambaIRv2: Attentive State Space Restoration的环境
  • Sql刷题日志(day5)
  • 说一下Redis的发布订阅模型和PipeLine
  • OpenBayes 一周速览|EasyControl 高效控制 DiT 架构,助力吉卜力风图像一键生成;TripoSG 单图秒变高保真 3D 模型
  • leetcode hot100尝试1
  • 零基础入门 Verilog VHDL:在线仿真与 FPGA 实战全流程指南
  • 鸿蒙中的并发线程间通信、线程间通信对象
  • 状态模式(State Pattern)详解
  • Python | 分层线性模型的实现及示例
  • 什么是鸿蒙南向开发?什么是北向开发?
  • PHP 反序列化原生类 TIPS字符串逃逸CVE 绕过漏洞属性类型特征
  • 泽连斯基提议乌俄“立即、全面和无条件”停火
  • 福建一改造项目1人高处坠亡且事故迟报41天,住建厅约谈相关责任单位
  • 威廉·透纳诞辰250周年|他是现代艺术之父
  • 宝马董事长:继续倡导自由贸易和开放市场,坚信全球性挑战需要多协作而非对立,将引入DeepSeek
  • 旁白丨无罪后领到国家补偿,一位退休教师卸下了“包袱”
  • 新片|真人版《星际宝贝史迪奇》5月23日与北美同步上映