Redisson 分布式锁原理与实战：从手写 SETNX 到看门狗避坑指南

从“超卖”说起为什么需要分布式锁先说一个我早年间踩过的坑。当时做一个电商秒杀活动商品库存只有 100 件用了常用的synchronized锁来控制扣库存。单机压测一切正常结果上线当晚就被运维电话叫醒——超卖了 30 多件。原因很简单synchronized只对单个 JVM 进程生效流量一上来多台应用服务器同时执行扣库存逻辑每台机器各自的锁互相之间根本不认识库存自然就崩了。你遇到这个场景第一反应可能是用 Redis 的SETNX自己写一把分布式锁。很多面试题里也会问“Redis 分布式锁怎么做”最基础的方案就是SET key value NX PX 30000感觉上没毛病拿不到锁就重试拿到锁就干活干完释放。但真放到生产环境这个手写方案会漏出一堆问题——锁被误删、锁过期导致并发、进程崩溃后死锁、可重入做不到。在我把“手写锁”干翻两次线上环境之后我彻底转投了 Redisson。这篇文章就把 Redisson 分布式锁的原理和我在实战中沉淀的用法、避坑经验一次性讲清楚希望能给正在自己造轮子或者卷分布式锁面试题的朋友一些参考。写这篇文章之前先界定一下读者范围。如果你已经理解 Redis 的基本数据结构但搞不清楚 Redisson 的看门狗、Lua 脚本、可重入到底怎么回事或者你正在 Spring Boot 项目里集成分布式锁但总担心锁不够安全那这篇文章适合你。如果你只是来背面试答案后面的源码级拆解也能帮你把“分布式锁面试题”答出深度。1. 内容整体设计与思路拆解1.1 分布式锁要解决的三个核心问题在聊 Redisson 之前先梳理分布式锁到底在锁什么。单机场景下synchronized和ReentrantLock锁的是 JVM 内存中的对象监视器多线程竞争同一个对象时自然互斥。到了分布式环境锁的本质变成“同一时刻多个进程之间只能有一个进程获得执行权限”。这就引出了三个必须解决的问题互斥性这是锁的根本目标。同一把锁同一时刻只能被一个客户端持有。在分布式环境下你需要一个所有进程都能访问到的公共存储来充当“锁的登记处”Redis 就是这个登记处。安全性持有锁的进程挂了锁必须能自动释放否则其他进程永远等下去形成死锁。这就需要一个“过期时间”兜底。正确性A 进程释放锁的时候不能把 B 进程刚拿到的锁释放掉。手写SETNX方案里最常见的事故就是A 持锁超过过期时间锁自动失效B 拿到锁开始干活此时 A 业务逻辑跑完执行DEL把 B 的锁删了。这种情况必须通过校验“锁持有者身份”来解决。Redisson 的整个设计都是围绕这三个问题展开的每个机制都能在它内部找到对应实现。这个思路很重要因为你理解了问题再看它的源码就不会觉得是黑魔法。1.2 手写 Redis 锁的典型方案与致命缺陷很多人面试时能背出“SETNX EXPIRE”两件套但实际生产环境远远不够。我列一个典型的手写锁代码// 错误示范仅用于分析问题 Boolean success stringRedisTemplate.opsForValue() .setIfAbsent(lock:order, requestId, 30, TimeUnit.SECONDS); if (success) { try { // 处理业务 doBiz(); } finally { // 释放锁时校验 value 是否为自己写入的 requestId if (requestId.equals(stringRedisTemplate.opsForValue().get(lock:order))) { stringRedisTemplate.delete(lock:order); } } }这个方案看着比最原始的SETNX好了很多加了过期时间防止死锁加了 requestId 防止误删别人的锁。但它仍然有四个问题。第一个问题是“校验删除”不是原子操作。get判断完是自己的锁之后在delete执行前锁刚好过期另一个进程抢到了锁此时delete就把别人的锁删了。要修复就得用 Lua 脚本把比对和删除合并成原子操作。第二个问题是锁过期时间不好拍。设置短了业务执行慢一点锁就提前过期并发立刻进来设置长了进程挂了锁要很久才释放拖慢整个集群。你无法为所有业务预估一个合适的固定过期时间。第三个问题是不可重入。同一个线程在执行持锁逻辑时再次调用加锁方法会被自己挡在门外直接死锁。synchronized天然支持可重入这个特性在分布式锁里却常常被忽略。第四个问题是获取锁的过程是纯自旋。没有等待机制、没有超时控制拿不到锁就一直循环请求 Redis高并发下 Redis 和业务线程都被拖垮。Redisson 的方案本质上是把这些坑全部填上了用 Lua 脚本保证原子性用看门狗动态续期用哈希结构实现可重入用信号量语义实现公平等待。理解了手写方案的这四宗罪你看 Redisson 源码时会非常有感觉——每个设计都有明确针对性。2. 核心细节解析与实操要点2.1 锁是怎么“抢”到的Lua 脚本与哈希结构Redisson 加锁的核心逻辑在RedissonLock#tryLockInnerAsync方法里最终会执行一段 Lua 脚本。记住一点Lua 脚本在 Redis 中是原子执行的这就解决了“检查-写入”分离带来的竞态问题。-- 简化版核心逻辑实际源码会多一层判断 if (redis.call(exists, KEYS[1]) 0) then redis.call(hset, KEYS[1], ARGV[2], 1); redis.call(pexpire, KEYS[1], ARGV[1]); return nil; end; if (redis.call(hexists, KEYS[1], ARGV[2]) 1) then redis.call(hincrby, KEYS[1], ARGV[2], 1); redis.call(pexpire, KEYS[1], ARGV[1]); return nil; end; return redis.call(pttl, KEYS[1]);KEYS[1] 是锁的 key比如lock:order。ARGV[2] 是客户端唯一标识通常是UUID 线程ID。ARGV[1] 是锁的过期时间默认 30000 毫秒。注意这里用的是哈希结构而不是普通的 string。HSET lock:order clientId 1表示“clientId 这个持有者持有了锁一次”。为什么用哈希就是为了支持可重入当同一个 clientId 再次加锁时走HINCRBY把计数器加一即可。锁的 key 本身没有变变的只是内部的 count。这个设计非常巧妙它让“锁”和“持有次数”天然绑定在同一个 Redis key 上。如果锁已经被别人持有脚本会返回当前锁的剩余存活时间PTTLJava 端拿到这个值就知道自己还得等多久。整个过程一个网络请求搞定不需要客户端做多次 Redis 调用。2.2 看门狗机制它如何解决锁过期问题看门狗Watchdog是 Redisson 分布式锁最亮眼的特性也几乎是所有“分布式锁面试题”的必考点。它的作用一句话说清楚默认情况下加锁成功后Redisson 会启动一个后台定时任务每 10 秒给锁续期一次把过期时间重置为 30 秒。这样业务线程只要还在执行锁就永远不会因为超时被释放。底层实现是 Netty 的一个Timeout任务。加锁成功返回后如果当前锁没有显式设置leaseTime租期看门狗就会被启动。它每隔internalLockLeaseTime / 3也就是 10 秒执行一次续期逻辑调用一段 Lua 脚本-- 简化版续期脚本 if (redis.call(hexists, KEYS[1], ARGV[2]) 1) then redis.call(pexpire, KEYS[1], ARGV[1]); return 1; end; return 0;如果锁还是被当前客户端持有就重置过期时间为 30 秒如果锁已经没了比如手动释放了续期逻辑自动停止。这个机制的坑点在于只有没有指定 leaseTime 时看门狗才会工作。如果你在调用lock()或tryLock()时手动传了锁时长Redisson 就认为你不需要自动续期到期直接释放。很多初学者在这上面栽过跟头——传了一个 10 秒的 leaseTime结果业务跑了 30 秒锁中途就没了还没反应过来。2.3 可重入与锁释放的完整闭环锁释放同样通过 Lua 脚本完成。核心逻辑是先判断锁持有人是否是自己是则把哈希里的计数器减一减完后如果计数仍大于 0说明该线程还有外层锁未释放只重置过期时间如果计数归零说明最外层锁也释放了直接删除整个 key 并发布一条解锁消息。-- 简化版释放脚本 if (redis.call(hexists, KEYS[1], ARGV[3]) 0) then return nil; end; local counter redis.call(hincrby, KEYS[1], ARGV[3], -1); if (counter 0) then redis.call(pexpire, KEYS[1], ARGV[1]); return 0; else redis.call(del, KEYS[1]); redis.call(publish, KEYS[2], ARGV[2]); return 1; end;这个脚本保证了释放锁的操作是原子的不会出现“删了别人的锁”的问题。哈希计数器归零才删 key 的设计也保证了可重入锁的正确语义——最外层释放才算真正释放。顺带提一个容易忽略的设计解锁成功后 Redisson 会publish一条消息到 Redis 的 channel。订阅这个 channel 的其他等待线程收到消息后会立即尝试抢锁而不是傻等下一个重试周期。这就让“锁竞争”变得高效是 Redisson 相比纯自旋方案体验好的重要原因之一。3. 实操过程与核心环节实现3.1 依赖引入与客户端配置我用的是 Spring Boot 项目引入 Redisson 的姿势非常傻瓜。以 3.x 版本为例Maven 依赖如下dependency groupIdorg.redisson/groupId artifactIdredisson-spring-boot-starter/artifactId version3.17.7/version /dependency然后在application.yml里配置 Redis 连接spring: redis: redisson: config: | singleServerConfig: address: redis://127.0.0.1:6379 password: null database: 0 threads: 16 nettyThreads: 32这里我直接用官方提供的 starter自动装配了RedissonClient。如果你的项目不是 Spring Boot也可以手写一个配置类Configuration public class RedissonConfig { Bean public RedissonClient redissonClient() { Config config new Config(); config.useSingleServer() .setAddress(redis://127.0.0.1:6379); return Redisson.create(config); } }说句实在话配置本身没有太多技术含量但有一个细节值得注意默认的 watchdog 时间30 秒和续期间隔10 秒不建议轻易调整。网上很多文章教你把 leaseTime 调大调小实际生产环境保持默认是最稳妥的。真要调也要先想清楚业务最大执行时间否则很容易引入锁提前失效或看门狗空转的问题。3.2 业务代码中加锁的三种姿势拿到RedissonClient之后核心 API 是getLock返回的RLock。我按使用场景把常见姿势拆成三种。第一种简单粗暴的lock()阻塞等待。RLock lock redissonClient.getLock(lock:order); lock.lock(); try { // 扣减库存业务 doDeductStock(); } finally { lock.unlock(); }注意lock()会一直阻塞到获取锁为止并且不传 leaseTime走看门狗自动续期。业务执行多久锁就保持多久非常适合不确定耗时的数据库操作。但如果业务线程一直拿不到锁它会无限等待下去所以这种姿势要求调用方对并发量和锁持有时间有充分预期。第二种带超时的tryLock()。boolean locked lock.tryLock(3, 10, TimeUnit.SECONDS); if (!locked) { // 快速失败返回提示比如 “当前下单人数过多” return; } try { doDeductStock(); } finally { if (lock.isHeldByCurrentThread()) { lock.unlock(); } }参数含义分别是等待时间 3 秒租期 10 秒。等待时间指的是拿不到锁时最多阻塞多久租期 10 秒代表手动指定锁 10 秒后自动过期看门狗在此场景下不生效。如果业务可能超过 10 秒就不能这么写。很多故障都是“我明明设置了 tryLock 的租期为什么锁还是提前释放了”——就是没搞清楚这个语义。第三种配合Lock注解做声明式锁。Redisson 提供了RLock的注解支持比如Lock(value lock:order, leaseTime 10, waitTime 3)。但这个注解依赖于 AOP内部还是调用上面那两个核心 API。我的习惯是优先用tryLock显式控制原因在于注解方式把锁范围隐藏在切面里排查问题时没那么直观。声明式锁适合团队规范约定清晰、代码评审严格的项目不适合“能用就行”的氛围。3.3 锁粒度设计别一把锁锁住所有请求分布式锁真正考验人的不是 API 用法而是锁粒度。锁的 key 设计决定并发上限这是我和很多同事反复踩过坑之后才有的体会。反面案例整个订单创建流程用lock:order加锁所有用户的所有订单都会竞争同一把锁并发能力归零。正确做法是按业务维度拆分 key比如把 key 拆成lock:order:userId:{userId}同一个用户的下单请求串行不同用户之间完全并发。这种思路在秒杀场景里要再细一点秒杀的关键不只是一个用户不能重复下单而是同一件商品不能被超卖所以锁 key 往往是lock:seckill:productId:{productId}。还有一种常见场景是防重复提交。比如 100 个请求同时打到“创建订单”接口你想只让一个请求成功。这种情况下锁 key 用用户ID 加操作类型就行配合tryLock快速失败体验比队列削峰简单得多。我每次设计锁 key 时都会先问自己三个问题这个锁要保护什么资源哪些请求访问同一资源不同资源的请求能否并行答案清晰了锁粒度自然合理。锁 key 千万别一个服务只定义一个这是新手最容易犯的错误。4. 常见问题与排查技巧实录4.1 锁失效的几种隐蔽场景我整理了一个速查表里面都是实际线上遇到过的场景每条背后都有真实事故不是网上抄来的概念。场景现象根本原因解决建议手动指定 leaseTime 但业务超时并发线程同时进入临界区锁到期自动释放watchdog 未介入不传 leaseTime或评估业务最坏耗时后预留 20% 余量使用 tryLock 后 unlock 报错IllegalMonitorStateException锁已过期自动释放当前线程已不持有锁释放前判断isHeldByCurrentThread()Redis 主从切换丢锁短暂的并发写入主节点故障锁 key 未同步到从节点容忍极小概率则用普通模式要求严格用 RedLock/数据库锁锁的 key 设置了固定前缀但没加业务维度同一 key 竞争极度激烈接口 RT 飙升锁粒度太粗按 userId/productId 拆分 key业务抛异常但 finally 里忘了 unlock锁持有时间无限延长看门狗一直续期释放逻辑缺失规范使用 try-finally并加监控报警第一个场景我实际遇到过一次。同事在秒杀接口里写lock.lock(10, TimeUnit.SECONDS)认为 10 秒绰绰有余。结果下游一个外部接口超时重试单次请求跑了 30 多秒锁在第 10 秒就没了多个线程同时扣减同一商品库存。事后复盘这个问题完全可以通过不传 leaseTime 交给看门狗来规避。所以我对团队的要求是除非对业务耗时极有把握否则一律用不带租期的lock()或者把租期设得足够大让看门狗兜底。4.2 参数调优租期、等待时间、重试次数Redisson 加锁的核心参数其实只有三四个但理解它们的组合效果很重要。等待时间waitTimetryLock的第一个参数。它决定了线程最多等多久。设得太长大量线程阻塞在锁上线程池容易被占满设得太短稍微有点竞争就直接失败体验差。我的经验值是 2~3 秒秒杀场景可以接受快速失败后台任务可以设 5~10 秒。租期leaseTime就是锁的自动过期时间。不传时交给看门狗传了就没有自动续期。这个参数的坑前面说过了不再赘述。唯一要补充的是如果你用带租期的写法租期理论值应该大于业务耗时峰值并且留出足够的 buffer因为锁过期时间到真正触发 Redis 清理之间还有网络延迟。重试次数/间隔tryLock底层默认会订阅锁释放的 channel所以它不是纯轮询。除非使用RedissonLock的lockInterruptibly等特殊方式一般不需要手动调重试。如果拿不到锁时希望控制行为写清楚 waitTime 更靠谱。我个人的调优习惯先固定 waitTime3sleaseTime 不传观察一个“锁等待超时”监控指标。如果等待超时次数高优先优化锁粒度不盲目调参数。参数调优解决不了设计问题锁粒度才是并发瓶颈的根源。4.3 集群/哨兵模式下锁的一致性风险Redisson 默认使用单节点模式的话Redis 主从切换时会有极小概率丢锁。我在实际生产里也有过这个担忧但这要分业务场景看。如果你的业务场景是“宁可偶尔出一点并发问题也不能阻塞核心链路”比如非金融类的活动营销那单节点 Redis Redisson 在 Redis 本身可用性达标的前提下是可以接受的。因为 Redisson 已经把原子性、续期、误删这些基础问题解决好了剩下的主从切换窗口很窄。如果你的业务场景是“绝对不允许并发”比如账务扣款那你就不能只靠 Redis 一把锁。Redisson 提供了RedissonRedLock基于 Redlock 算法需要向多个独立 Redis 节点同时加锁且多数节点成功才算加锁成功。但这里我要泼一盆冷水Redlock 在分布式系统领域本身也存在争议代码复杂度高运维成本高多数时候 MySQL 的行锁反而更可靠。真实项目里我的选型逻辑是有数据库兜底的场景优先用数据库悲观锁SELECT FOR UPDATE没有数据库事务兜底但容忍极少并发的场景用 Redisson对严格一致性有硬要求的金融场景直接引入 ZooKeeper/etcd 或者上 MQ 串行化。分布式锁没有银弹Redisson 只是在“简单、可靠、易用”这个维度上做到了极致平衡。4.4 排查分布式锁问题的独家思路线上遇到分布式锁相关故障我通常会按这个顺序排查。第一看监控确认锁等待时间和持有时间。Redisson 没有现成的内置监控但我会在业务代码里手动记录加锁耗时和解锁耗时打印到日志里。锁平均等待时间突然变长说明锁竞争加剧优先检查“锁 key 是否被写死”了。第二看 Redis 慢日志。如果锁操作大量出现在慢日志里说明 Redis 本身可能有大 key、热 key 问题或者锁 key 过期时间设置过短导致频繁重试。第三复现并发场景模拟锁超时和主从切换。本地起两个 Spring Boot 实例用同一个 Redis通过脚本高频调用加锁接口观察是否有两个线程同时进入临界区。这一步能快速验证看门狗和 Lua 脚本是否按预期工作。第四检查客户端版本。Redisson 的 bug 修复速度很快3.15 和 3.17 之间就有不少锁相关的修复。如果线上事故反复出现先看版本是不是太老。我曾经升级 Redisson 版本解决过一个偶发的“解锁报错导致线程卡死”问题这个排查思路在社区很多讨论帖里也常见。最后想说的话在实际项目里Redisson 分布式锁解决了我太多的“手写锁事故”。它的 Lua 脚本原子性、看门狗续期、可重入设计每一块都是针对分布式锁核心问题精心打磨过的。使用它并不难难的是正确理解每个参数背后的语义以及把锁粒度设计到和业务模型完全匹配。我也见过不少团队把 Redisson 当成万能钥匙——不管什么场景上来就加锁反而把性能拖垮了。我个人的体感是能通过业务设计避免并发冲突比如幂等表、版本号、状态机就尽量不引入锁必须加锁的时候Redisson 是最省心的那一个选择。碰到“锁没生效”的诡异问题时先检查 leaseTime 和看门狗再检查锁 key 的设计最后检查 Redis 集群模式——按这个顺序九成问题都能定位到根因。这套排查思路在我手上救过好几次大促希望你也能用上。