Redisson 的分布式锁

Redisson 的分布式锁基于 Redis 实现,通过原子操作、可重入设计、看门狗续期等机制保障高并发场景下的数据一致性。以下从核心机制、实现原理、典型场景图解及缺陷分析展开详解:

核心机制与实现原理

1.获取锁
2.加锁机制(Lua脚本原子操作)
java 复制代码
if redis.call('exists', KEYS[1]) == 0 then  -- 锁不存在
    redis.call('hset', KEYS[1], ARGV[2], 1)  -- 创建Hash:KEYS[1]=锁名,ARGV[2]=客户端ID+线程id,Value=1(锁重入次数)
    redis.call('pexpire', KEYS[1], ARGV[1])  -- ARGV[1]=设置过期时间(默认30s)
    return nil 
end 
if redis.call('hexists', KEYS[1], ARGV[2]) == 1 then  -- 锁存在且为当前线程
    redis.call('hincrby', KEYS[1], ARGV[2], 1)  -- 重入次数+1
    redis.call('pexpire', KEYS[1], ARGV[1])      -- 刷新过期时间
    return nil 
end 
return redis.call('pttl', KEYS[1])  -- 返回锁剩余生存时间(供其他线程等待)
3. 可重入性

同一线程多次加锁时,Hash 中的 Value 值递增(12→3...),解锁时递减至 0 才删除锁 Key;

可重入性降低锁的竞争,提高系统性能

4.锁互斥性与等待重试
  • 其他线程加锁 :若锁已被占用,返回剩余生存时间(TTL),客户端进入 while 循环自旋,并通过 Redis 的 pub/sub 订阅解锁消息。

  • 唤醒机制:锁释放时发布消息,通过释放信号量唤醒等待线程竞争锁(避免无效轮询)

5. 解锁流程
java 复制代码
if redis.call('hexists', KEYS[1], ARGV[3]) == 0 then  -- 非当前线程的锁
    return nil 
end 
local counter = redis.call('hincrby', KEYS[1], ARGV[3], -1)  -- 重入次数-1
if counter > 0 then 
    redis.call('pexpire', KEYS[1], ARGV[2])  -- 重置过期时间
    return 0 
else 
    redis.call('del', KEYS[1])                 -- 删除Key
    redis.call('publish', KEYS[2], ARGV[1])    -- 发布解锁消息
    return 1 
end 
6.锁超时续期

看门狗自动续期(Watchdog)

触发条件 :未显式设置 leaseTime 时启用

流程

  1. 加锁成功后启动后台线程,每隔 10秒(默认)检查锁是否被当前线程持有。

  2. 若持有,则重置锁过期时间为 30秒

  1. 未显式设置 leaseTime (或 leaseTime = -1):启用看门狗机制

    • 当你使用 lock() 方法加锁时,默认行为就是 启用看门狗

    • 此时,Redisson 会为锁设置一个默认的锁超时时间(通常是 lockWatchdogTimeout 配置的值,默认 30 秒)。

    • 看门狗机制(一个后台线程)会在锁持有期间,定期 (默认在锁超时时间的 1/3 时,即 10 秒后开始)检查客户端是否仍然持有该锁。如果客户端还持有锁,看门狗会自动将锁的超时时间重置回默认值(30秒),从而避免锁因为业务执行时间过长而意外过期释放。

    • 这种模式适用于不知道业务具体需要执行多久 ,希望锁能一直被持有直到业务完成并显式调用 unlock() 的场景。看门狗确保了只要客户端进程还"活着"且持有锁意图,锁就不会自动过期。

  2. 显式设置 leaseTime > 0:禁用看门狗机制

    • 当你使用 lock(long leaseTime, TimeUnit unit)tryLock(long waitTime, long leaseTime, TimeUnit unit) 等方法,并明确指定了一个大于 0leaseTime 值时,Redisson 会禁用看门狗机制

    • 此时,你设置的 leaseTime 就是锁的绝对生存时间 。锁会在加锁成功后的 leaseTime 时间后自动过期释放,无论业务逻辑是否执行完毕,也无论客户端是否仍然存活。

    • 后台没有线程会去自动续期这个锁。

    • 这种模式适用于能够预估业务最大执行时间 的场景。你需要确保设置的 leaseTime 大于 业务逻辑可能执行的最长时间,否则锁可能在业务完成前就自动释放,导致数据不一致。同时,业务逻辑执行完毕后,最好还是显式调用 unlock() 来及时释放锁,避免无谓的等待。

风险:业务死循环可能导致锁永久占用

7.正常加锁与续期

相关推荐
拾忆,想起2 小时前
Redis红锁(RedLock)解密:分布式锁的高可用终极方案
java·数据库·redis·分布式·缓存·性能优化·wpf
小白学大数据5 小时前
Scrapy 框架实战:构建高效的快看漫画分布式爬虫
开发语言·分布式·爬虫·python·scrapy
项目題供诗5 小时前
Hadoop(六)
大数据·hadoop·分布式
Hello.Reader9 小时前
Kafka 4.0 五大 API 选型指南、依赖坐标、上手示例与最佳实践
分布式·kafka·linq
青云交15 小时前
Java 大视界 -- 基于 Java 的大数据实时流处理在智能电网分布式电源接入与电力系统稳定性维护中的应用(404)
java·大数据·分布式·智能电网·flink 实时流处理·kafka 数据采集·iec 61850 协议
Monkey-旭1 天前
鸿蒙 5.1 深度解析:ArkUI 4.1 升级与分布式开发新范式
分布式·wpf·harmonyos·arkts·openharmony·arkui
猿java1 天前
分布式和微服务,它们有什么区别?该如何选择?
分布式·微服务·架构
hello 早上好1 天前
基于 Spring AMQP 的 RabbitMQ 分布式消息系统实战
分布式·spring·java-rabbitmq
哈基米喜欢哈哈哈2 天前
Kafka复制机制
笔记·分布式·后端·kafka
孫治AllenSun2 天前
【Kafka】重点概念和架构总结
分布式·架构·kafka