做后端开发的这几年Redis分布式锁几乎成了绕不开的话题。不管是秒杀抢购、订单防重还是定时任务在集群环境下的互斥调度大家的第一反应往往都是“用Redis搞一把分布式锁”。我最初也是这么干的——SETNX一把梭结果线上踩了几次坑之后才明白Redis分布式锁看似简单真要落地到生产环境里面值得深挖的细节远比想象中多。这篇文章不是把官方文档抄一遍而是把我从“会用”到“敢在生产环境用”的完整思路整理出来包括最基础的实现原理、Redisson看门狗机制、RedLock方案的争议以及真正实操时容易踩的那些坑。适合正在学分布式锁的开发者也适合已经在用但还没系统梳理过原理的同学参考。1. 为什么要分布式锁从一个超卖事故说起先讲一个典型的场景。某电商团队搞了一次秒杀活动库存1000件结果订单系统显示卖出了1200件。排查下来问题出在并发控制上——应用是集群部署多台机器同时扣库存原来的Synchronized锁只能在单台机器内部生效根本管不住其他机器的线程。这就是分布式锁最核心的价值在多个进程、多台机器之间实现互斥访问。单机版的锁Synchronized、ReentrantLock管的是JVM内部的线程分布式锁管的是跨进程的资源访问。1.1 分布式锁要满足的四个硬性条件做分布式锁之前先理清楚它到底要满足什么要求否则后面实现的时候很容易漏掉关键点。互斥性同一时刻只能有一个客户端持有锁。这是锁的基本底线做不到互斥后面全都白谈。防死锁持有锁的客户端如果崩溃或者网络异常锁必须能自动释放否则其他客户端会永远等下去。高可用与容错锁服务本身要稳定至少不能因为锁导致业务雪崩。加锁解锁的原子性判断锁是否存在、设置锁、释放锁这些操作必须是原子的不能有中间态。除了这四点还有两个容易被忽略的进阶要求可重入同一个线程可以重复获取同一把锁和性能开销可控。1.2 为什么选Redis而不是数据库或ZooKeeper市面上的分布式锁方案不止Redis一种常见的有数据库行锁、ZooKeeper临时有序节点、etcd、Redis。我用一张表说清楚各自的取舍。方案性能可靠性实现复杂度适用场景数据库行锁/乐观锁中等中等低低频、对一致性要求高Redis分布式锁高中高中高并发、可接受短暂失效ZooKeeper/etcd较低高较高强一致、对可靠性要求极高Redis的优势非常明显单线程模型让命令执行天然串行性能极高SET命令配合NX参数能把“判断写入”做成一步操作语义简洁客户端生态成熟像Redisson这样的框架已经把大部分细节封装好了。劣势也同样明显它的一致性模型是AP的极端场景下可能出现锁丢失后面单独讲RedLock时细说。2. 核心原理拆解从SETNX到看门狗的演进逻辑Redis分布式锁不是一天变成现在这个样子的它的演进过程本身就是一部避坑史。我把这个过程拆开讲你就能理解为什么现在的写法长这样。2.1 最原始的版本SETNX加EXPIRE为什么不行最早的时候大家用SETNX加锁SETNX lockKey uniqueValue EXPIRE lockKey 30SETNX的意思是“Set if Not eXists”只有key不存在时才能设置成功返回值1表示拿到锁0表示锁被别人持有。这个思路没错但问题在于SETNX和EXPIRE是两个独立的命令中间存在一个时间窗口。如果客户端在执行完SETNX之后、执行EXPIRE之前突然宕机那么lockKey就永远不会过期这把锁就成了死锁其他所有客户端都会阻塞。这就是典型的“非原子操作”带来的隐患。2.2 原子加锁SET key value NX EX seconds后来的解决方案是把两条命令合并成一条SET lockKey uniqueValue NX EX 30这条命令整体是原子的Redis在执行时会同时完成“判断key是否存在”和“设置过期时间”两个动作彻底消除了崩溃窗口期。注意这里的NX和EX是两个参数含义分别是“仅当key不存在时设置”和“设置过期时间为30秒”。这里还有一个容易被忽略的细节value为什么要设置成唯一标识因为释放锁的时候需要校验“这个锁是不是我持有的”如果用固定值就会出现误删别人锁的问题。2.3 Lua脚本解锁为什么判断和删除必须打包释放锁的时候逻辑看起来很简单先GET锁的value如果等于自己的唯一标识就DEL掉。if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end这整段逻辑要用Lua脚本执行因为Redis能保证Lua脚本在执行过程中不会被其他命令打断。如果你先GET再DEL两个操作之间有间隔可能会出现这么个情况锁恰好过期被B客户端拿到A客户端GET到的还是自己的value直接DEL就把B的锁删了。用Lua脚本把两步合并这个问题就没了。2.4 Redisson看门狗机制让锁自己续命手写的版本还有一个老大难问题锁的过期时间到底设多少。设短了业务还没执行完锁就过期了设长了万一线程真的挂了其他客户端要多等很久。Redisson的解决方案是看门狗机制。它的默认逻辑是这样的加锁时默认leaseTime是30秒如果业务没指定过期时间看门狗就会启动。后台有一个定时任务每10秒检查一次锁是否还被当前线程持有。如果还在持有就把锁的过期时间重置回30秒相当于“续命”。业务执行完unlock时取消定时任务释放锁。这个机制解决了我前面说的“过期时间设多少”的问题让你不用预估业务耗时锁会自动适配。不过要注意看门狗只在你没手动指定leaseTime时才生效如果你调用了lock(10, TimeUnit.SECONDS)这样的方法Redisson就认为你明确知道要锁多久不会再帮你续期。3. 手写实现到工程落地分布式锁的完整代码与参数选择说了这么多原理还是得上代码。我按从简到繁的顺序给你三套方案前两套自己学习用最后一套生产直接抄作业。3.1 手写版用Jedis实现最基础的分布式锁先看加锁使用Jedis客户端public boolean tryLock(String lockKey, String requestId, int expireSeconds) { // SET lockKey requestId NX EX expireSeconds String result jedis.set(lockKey, requestId, NX, EX, expireSeconds); return OK.equals(result); }这里requestId建议用UUID字符串每次加锁生成一个作为当前线程持有锁的凭证。为什么不用线程ID因为多实例部署的情况下不同机器的线程ID可能重复UUID更可靠。再看解锁用Lua脚本保证原子性public boolean unlock(String lockKey, String requestId) { String luaScript if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; Object result jedis.eval(luaScript, Collections.singletonList(lockKey), Collections.singletonList(requestId)); return Long.valueOf(1L).equals(result); }这套代码看起来能用了但它没有看门狗锁过期后业务没执行完的问题依然存在。你可以自己用定时任务模拟续期但说实话生产环境我强烈不建议手写这套轮子一半以上的坑我都踩过。3.2 生产版Redisson的正确打开方式Redisson把前面讲的所有逻辑都封装好了包括看门狗、可重入、Lua脚本释放锁还支持读写锁和公平锁。先加依赖dependency groupIdorg.redisson/groupId artifactIdredisson-spring-boot-starter/artifactId version3.20.1/version /dependency基础用法长这样Resource private RedissonClient redissonClient; public void processOrder(Long orderId) { String lockKey order:pay: orderId; RLock lock redissonClient.getLock(lockKey); try { // 尝试加锁最多等待3秒上锁后10秒自动解锁 boolean isLocked lock.tryLock(3, 10, TimeUnit.SECONDS); if (!isLocked) { throw new RuntimeException(系统繁忙请稍后再试); } // 执行业务逻辑 doBusiness(orderId); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } finally { // 注意只有拿到锁的线程才能解锁 if (lock.isHeldByCurrentThread()) { lock.unlock(); } } }这套代码有几个关键点值得解释。第一tryLock的三个参数含义分别是等待获取锁的最大时间、锁的自动释放时间、时间单位。如果等待时间超过3秒还没拿到锁就直接返回失败避免请求无限阻塞。第二手动指定了leaseTime之后看门狗就不会生效了。你明确告诉Redisson锁10秒后释放它不会帮你续期。如果不指定leaseTime只写lock.tryLock(3, TimeUnit.SECONDS)看门狗才会启动。生产环境中如果你不确定业务耗时建议用看门狗模式如果你很清楚业务最多5秒能跑完就直接指定leaseTime。第三解锁前一定要判断isHeldByCurrentThread()。这里其实也隐含了一个问题如果你在没拿到锁的情况下调用unlockRedisson会直接抛IllegalMonitorStateException所以在finally里加这个判断是安全的写法。3.3 锁粒度与性能优化千万别用一把锁管所有订单刚上手分布式锁的时候我犯过一个典型错误把所有订单共用一把锁。// 错误示范全局一把锁性能急剧下降 RLock lock redissonClient.getLock(order:global);这样写虽然避免了并发问题但所有订单的加锁操作都串行化了Redis的QPS再高也扛不住业务吞吐量的需求。正确的做法是尽量把锁粒度做小比如按订单维度加锁锁Key用order:pay:{orderId}。订单之间互不影响只有同一个订单的并发操作才会互相等待。锁粒度直接决定了分布式锁的性能上限。锁的范围越小并发能力越高锁的范围越大代码越简单但吞吐量越低。工程上要在这两者之间找平衡。3.4 高并发下的加锁策略快速失败与阻塞等待如何选获取锁失败之后业务应该怎么办两种主流策略各有适用场景。第一种是快速失败。拿不到锁直接返回“系统繁忙”或者抛异常让用户重试。这种策略适合秒杀、防重提交等场景用户能接受偶尔失败系统也不希望请求堆积。第二种是阻塞重试。拿不到锁就自旋等待每隔一段时间重新尝试加锁直到超时。这种方式适合任务调度类的场景比如定时任务就希望确保执行慢一点没关系。但自旋重试要注意控制重试频率不然就是传说中的羊群效应——大量请求同时去抢锁Redis压力骤增。Redisson的tryLock(waitTime, leaseTime, unit)实际上就是第二种的封装waitTime参数控制了最大等待时长。我个人的习惯是面向用户的接口用快速失败后台任务用阻塞重试。4. RedLock方案与争议边界极端场景到底能不能用前面讲的都是单节点Redis实现分布式锁。如果Redis是主从架构有一个问题会让人很不安客户端A在Master上拿到了锁但Master还没来得及把这个key同步给Slave就宕机了Slave被选举成新的Master此时客户端B也能在新Master上拿到同一把锁。这就出现了两个客户端同时持有锁的情况互斥性被打破。为了解决这个问题就有人提出了RedLock算法。4.1 RedLock算法的核心逻辑RedLock的思路是既然单个Redis节点不可靠那就向多个独立的Redis节点请求加锁只在大多数节点上都加锁成功才认为真正拿到了分布式锁。具体步骤大致是这样客户端向N个独立的Redis节点官方建议N5同时发送SET锁请求使用相同的key和value。计算加锁的耗时只有满足两个条件才算加锁成功超过N/21个节点加锁成功且总耗时小于锁的有效期。加锁成功后锁的有效期要减去加锁的耗时。释放锁时向所有节点发送DEL命令。这个算法就是为了让锁的持有方冗余化单个节点挂掉不影响整体。4.2 业界对RedLock的知名质疑RedLock一出来就引发了分布式系统领域的大讨论。某位专门研究分布式一致性的专家指出RedLock本质上是一个基于“时间假设”的方案它依赖所有Redis节点的时钟大致同步但现实世界里节点时钟可能发生跳跃一旦时钟回拨锁的有效期就会被错误计算导致多个客户端同时持有锁。Redis的作者则坚持RedLock在实践中是可用的反对意见更多是理论层面的极端场景。这场争论其实没有绝对结论但它给我们一个非常重要的启发Redis分布式锁是“高可用”方案不是“强一致”方案。如果你的业务在锁失效的极端情况下会产生资金损失或不可逆的后果那就要慎重。4.3 我的工程取舍建议在真实项目中我没有对RedLock完全迷信也不会完全否定它。我更倾向于按场景分情况处理常规业务场景比如接口防重、订单状态流转单节点Redis配上主从切换已经足够。即使锁出现短暂失效业务底层还有数据库唯一索引兜底。对并发正确性要求极高的场景比如库存扣减、账户扣款我建议在Redis锁之外再加一层数据库乐观锁或版本号校验做到“双保险”。单纯依赖任何一种分布式锁都不是绝对安全的做法。工程的参考系应该放在整个系统的链路上而不是锁本身。有个观点我想强调一下分布式锁只是并发控制的手段之一不是万能药。一个成熟的系统通常会在数据库层做唯一约束在服务层做分布式锁在资源侧做幂等设计三层叠加才能把并发问题控制住。5. 实战避坑指南这些问题我几乎都遇到过这一章我直接整理一个排查速查表都是实际生产环境里可能遇到的典型问题。问题现象根本原因解决方案拿到锁后执行完删除了别人的锁释放锁时没有判断value是否自己的用Lua脚本校验唯一标识后再删业务没跑完锁就过期了过期时间设置不合理未用看门狗使用Redisson默认看门狗或合理估算耗时同一线程进入两次加锁代码就死锁锁不可重入使用Redisson的可重入锁或自己用hash结构实现Master宕机后锁失效两个线程同时执行业务主从复制异步锁数据未同步接受短暂失效或引入RedLock或业务做幂等大量线程同时等待锁Redis CPU飙升自旋重试导致羊群效应控制重试频率用Redisson的等待机制代替自旋5.1 锁误删问题为什么这么隐蔽锁误删的经典场景是这样的线程A拿到锁因为GC停顿或网络延迟业务执行超过了锁的过期时间。此时锁自动释放线程B拿到锁开始执行。线程A缓过劲来执行完了在finally里执行DEL直接把线程B的锁删了。线程C又能拿到锁了。这就是为什么释放锁必须校验唯一标识的原因。用Lua脚本把“GET判断DEL删除”合并成原子操作能杜绝这个问题。但要注意误删锁的场景往往是你根本意识不到锁过期了的场景所以就算代码写得再严谨也要设计好业务对幂等性的容忍度。5.2 看门狗过期时间到底怎么调很多人问我Redisson的默认30秒会不会太长万一线程真的挂了其他线程不是要等30秒吗实际测试下来Redisson的30秒设计是有道理的。它配合10秒轮询续期能让锁在正常业务下无限续期同时把异常场景下的等待时间控制在可接受范围内。如果你觉得30秒太久可以通过Config修改lockWatchdogTimeout参数但我一般不建议调到10秒以下否则网络抖动一次就可能续期失败锁提前释放。5.3 如何测试Redis分布式锁的可靠性测试分布式锁常规的JUnit单元测试根本测不出问题必须上并发压测模拟多线程抢占。我提供一个思路搭建两个应用实例指向同一个Redis模拟集群环境。写一个并发任务每轮任务都执行“加锁、睡眠500毫秒模拟业务、解锁”。用一个计数器统计同时进入临界区的线程数量理论上任何时刻这个计数器的值都不能超过1。测试过程中手动重启一个实例或者用kill -9模拟宕机观察锁能否正常释放。我踩过最深的坑是单机测试一切正常上了集群就出问题。所以分布式锁的测试环境一定要接近生产环境至少要让多实例同时跑。5.4 加锁Key设计的统一规范最后提一个工程上的细节。锁Key的命名规范非常重要我见过很多团队因为Key命名混乱导致出了bug都无从排查。建议统一格式业务场景:资源类型:资源ID。比如order:pay:123456 coupon:use:888888 inventory:deduct:SKU1001这样既方便定位哪把锁出了问题也能在Redis客户端里按前缀搜索到所有锁对监控和排查都有帮助。命名规范这种东西看起来不起眼关键时刻能省下大把排障时间。5.5 如何监控分布式锁的健康状况线上环境最好把锁的获取耗时、等待时间、锁冲突次数这几个指标暴露出来。Redisson通过RLock本身没有现成的监控指标但你可以封装一层自己的锁工具类在加锁成功和失败的地方加上日志或埋点。我一般会记录三个数据点加锁等待时间、锁冲突次数、锁自动过期次数。锁自动过期次数尤其重要它间接反映了你设置的过期时间是不是合理或者业务是不是有慢查询。如果这个数字持续增长说明有线程频繁在锁过期后才完成业务这是严重的并发隐患。结尾的实操心得根据我个人在实际项目里的使用经验Redis分布式锁最推荐的落地方式就是优先使用Redisson不要自己造轮子业务侧配合幂等设计不要把锁当作唯一的并发防线锁粒度尽量小能按订单就按订单不要搞全局锁。有一个细节想单独提一下因为我一开始就栽在这里在Spring中如果RedissonClient是单例注入千万不要手动去关闭它。很多人习惯在方法结束的时候调用redissonClient.shutdown()导致后续所有请求都拿不到客户端报各种连接异常。RedissonClient的生命周期应该跟随应用不是跟随请求。Redis分布式锁这个话题每次深入一层都有新收获。从SETNX一把梭到理解看门狗、RedLock的局限这个过程本身就是对分布式系统认知的提升。如果你也在用Redis做分布式锁建议把这篇文章里的几个场景自己动手复现一遍特别是并发测试和切换时钟的例子。踩过这些坑之后你才算真正理解了这把“锁”。
做后端开发的这几年Redis分布式锁几乎成了绕不开的话题。不管是秒杀抢购、订单防重还是定时任务在集群环境下的互斥调度大家的第一反应往往都是“用Redis搞一把分布式锁”。我最初也是这么干的——SETNX一把梭结果线上踩了几次坑之后才明白Redis分布式锁看似简单真要落地到生产环境里面值得深挖的细节远比想象中多。这篇文章不是把官方文档抄一遍而是把我从“会用”到“敢在生产环境用”的完整思路整理出来包括最基础的实现原理、Redisson看门狗机制、RedLock方案的争议以及真正实操时容易踩的那些坑。适合正在学分布式锁的开发者也适合已经在用但还没系统梳理过原理的同学参考。1. 为什么要分布式锁从一个超卖事故说起先讲一个典型的场景。某电商团队搞了一次秒杀活动库存1000件结果订单系统显示卖出了1200件。排查下来问题出在并发控制上——应用是集群部署多台机器同时扣库存原来的Synchronized锁只能在单台机器内部生效根本管不住其他机器的线程。这就是分布式锁最核心的价值在多个进程、多台机器之间实现互斥访问。单机版的锁Synchronized、ReentrantLock管的是JVM内部的线程分布式锁管的是跨进程的资源访问。1.1 分布式锁要满足的四个硬性条件做分布式锁之前先理清楚它到底要满足什么要求否则后面实现的时候很容易漏掉关键点。互斥性同一时刻只能有一个客户端持有锁。这是锁的基本底线做不到互斥后面全都白谈。防死锁持有锁的客户端如果崩溃或者网络异常锁必须能自动释放否则其他客户端会永远等下去。高可用与容错锁服务本身要稳定至少不能因为锁导致业务雪崩。加锁解锁的原子性判断锁是否存在、设置锁、释放锁这些操作必须是原子的不能有中间态。除了这四点还有两个容易被忽略的进阶要求可重入同一个线程可以重复获取同一把锁和性能开销可控。1.2 为什么选Redis而不是数据库或ZooKeeper市面上的分布式锁方案不止Redis一种常见的有数据库行锁、ZooKeeper临时有序节点、etcd、Redis。我用一张表说清楚各自的取舍。方案性能可靠性实现复杂度适用场景数据库行锁/乐观锁中等中等低低频、对一致性要求高Redis分布式锁高中高中高并发、可接受短暂失效ZooKeeper/etcd较低高较高强一致、对可靠性要求极高Redis的优势非常明显单线程模型让命令执行天然串行性能极高SET命令配合NX参数能把“判断写入”做成一步操作语义简洁客户端生态成熟像Redisson这样的框架已经把大部分细节封装好了。劣势也同样明显它的一致性模型是AP的极端场景下可能出现锁丢失后面单独讲RedLock时细说。2. 核心原理拆解从SETNX到看门狗的演进逻辑Redis分布式锁不是一天变成现在这个样子的它的演进过程本身就是一部避坑史。我把这个过程拆开讲你就能理解为什么现在的写法长这样。2.1 最原始的版本SETNX加EXPIRE为什么不行最早的时候大家用SETNX加锁SETNX lockKey uniqueValue EXPIRE lockKey 30SETNX的意思是“Set if Not eXists”只有key不存在时才能设置成功返回值1表示拿到锁0表示锁被别人持有。这个思路没错但问题在于SETNX和EXPIRE是两个独立的命令中间存在一个时间窗口。如果客户端在执行完SETNX之后、执行EXPIRE之前突然宕机那么lockKey就永远不会过期这把锁就成了死锁其他所有客户端都会阻塞。这就是典型的“非原子操作”带来的隐患。2.2 原子加锁SET key value NX EX seconds后来的解决方案是把两条命令合并成一条SET lockKey uniqueValue NX EX 30这条命令整体是原子的Redis在执行时会同时完成“判断key是否存在”和“设置过期时间”两个动作彻底消除了崩溃窗口期。注意这里的NX和EX是两个参数含义分别是“仅当key不存在时设置”和“设置过期时间为30秒”。这里还有一个容易被忽略的细节value为什么要设置成唯一标识因为释放锁的时候需要校验“这个锁是不是我持有的”如果用固定值就会出现误删别人锁的问题。2.3 Lua脚本解锁为什么判断和删除必须打包释放锁的时候逻辑看起来很简单先GET锁的value如果等于自己的唯一标识就DEL掉。if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end这整段逻辑要用Lua脚本执行因为Redis能保证Lua脚本在执行过程中不会被其他命令打断。如果你先GET再DEL两个操作之间有间隔可能会出现这么个情况锁恰好过期被B客户端拿到A客户端GET到的还是自己的value直接DEL就把B的锁删了。用Lua脚本把两步合并这个问题就没了。2.4 Redisson看门狗机制让锁自己续命手写的版本还有一个老大难问题锁的过期时间到底设多少。设短了业务还没执行完锁就过期了设长了万一线程真的挂了其他客户端要多等很久。Redisson的解决方案是看门狗机制。它的默认逻辑是这样的加锁时默认leaseTime是30秒如果业务没指定过期时间看门狗就会启动。后台有一个定时任务每10秒检查一次锁是否还被当前线程持有。如果还在持有就把锁的过期时间重置回30秒相当于“续命”。业务执行完unlock时取消定时任务释放锁。这个机制解决了我前面说的“过期时间设多少”的问题让你不用预估业务耗时锁会自动适配。不过要注意看门狗只在你没手动指定leaseTime时才生效如果你调用了lock(10, TimeUnit.SECONDS)这样的方法Redisson就认为你明确知道要锁多久不会再帮你续期。3. 手写实现到工程落地分布式锁的完整代码与参数选择说了这么多原理还是得上代码。我按从简到繁的顺序给你三套方案前两套自己学习用最后一套生产直接抄作业。3.1 手写版用Jedis实现最基础的分布式锁先看加锁使用Jedis客户端public boolean tryLock(String lockKey, String requestId, int expireSeconds) { // SET lockKey requestId NX EX expireSeconds String result jedis.set(lockKey, requestId, NX, EX, expireSeconds); return OK.equals(result); }这里requestId建议用UUID字符串每次加锁生成一个作为当前线程持有锁的凭证。为什么不用线程ID因为多实例部署的情况下不同机器的线程ID可能重复UUID更可靠。再看解锁用Lua脚本保证原子性public boolean unlock(String lockKey, String requestId) { String luaScript if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; Object result jedis.eval(luaScript, Collections.singletonList(lockKey), Collections.singletonList(requestId)); return Long.valueOf(1L).equals(result); }这套代码看起来能用了但它没有看门狗锁过期后业务没执行完的问题依然存在。你可以自己用定时任务模拟续期但说实话生产环境我强烈不建议手写这套轮子一半以上的坑我都踩过。3.2 生产版Redisson的正确打开方式Redisson把前面讲的所有逻辑都封装好了包括看门狗、可重入、Lua脚本释放锁还支持读写锁和公平锁。先加依赖dependency groupIdorg.redisson/groupId artifactIdredisson-spring-boot-starter/artifactId version3.20.1/version /dependency基础用法长这样Resource private RedissonClient redissonClient; public void processOrder(Long orderId) { String lockKey order:pay: orderId; RLock lock redissonClient.getLock(lockKey); try { // 尝试加锁最多等待3秒上锁后10秒自动解锁 boolean isLocked lock.tryLock(3, 10, TimeUnit.SECONDS); if (!isLocked) { throw new RuntimeException(系统繁忙请稍后再试); } // 执行业务逻辑 doBusiness(orderId); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } finally { // 注意只有拿到锁的线程才能解锁 if (lock.isHeldByCurrentThread()) { lock.unlock(); } } }这套代码有几个关键点值得解释。第一tryLock的三个参数含义分别是等待获取锁的最大时间、锁的自动释放时间、时间单位。如果等待时间超过3秒还没拿到锁就直接返回失败避免请求无限阻塞。第二手动指定了leaseTime之后看门狗就不会生效了。你明确告诉Redisson锁10秒后释放它不会帮你续期。如果不指定leaseTime只写lock.tryLock(3, TimeUnit.SECONDS)看门狗才会启动。生产环境中如果你不确定业务耗时建议用看门狗模式如果你很清楚业务最多5秒能跑完就直接指定leaseTime。第三解锁前一定要判断isHeldByCurrentThread()。这里其实也隐含了一个问题如果你在没拿到锁的情况下调用unlockRedisson会直接抛IllegalMonitorStateException所以在finally里加这个判断是安全的写法。3.3 锁粒度与性能优化千万别用一把锁管所有订单刚上手分布式锁的时候我犯过一个典型错误把所有订单共用一把锁。// 错误示范全局一把锁性能急剧下降 RLock lock redissonClient.getLock(order:global);这样写虽然避免了并发问题但所有订单的加锁操作都串行化了Redis的QPS再高也扛不住业务吞吐量的需求。正确的做法是尽量把锁粒度做小比如按订单维度加锁锁Key用order:pay:{orderId}。订单之间互不影响只有同一个订单的并发操作才会互相等待。锁粒度直接决定了分布式锁的性能上限。锁的范围越小并发能力越高锁的范围越大代码越简单但吞吐量越低。工程上要在这两者之间找平衡。3.4 高并发下的加锁策略快速失败与阻塞等待如何选获取锁失败之后业务应该怎么办两种主流策略各有适用场景。第一种是快速失败。拿不到锁直接返回“系统繁忙”或者抛异常让用户重试。这种策略适合秒杀、防重提交等场景用户能接受偶尔失败系统也不希望请求堆积。第二种是阻塞重试。拿不到锁就自旋等待每隔一段时间重新尝试加锁直到超时。这种方式适合任务调度类的场景比如定时任务就希望确保执行慢一点没关系。但自旋重试要注意控制重试频率不然就是传说中的羊群效应——大量请求同时去抢锁Redis压力骤增。Redisson的tryLock(waitTime, leaseTime, unit)实际上就是第二种的封装waitTime参数控制了最大等待时长。我个人的习惯是面向用户的接口用快速失败后台任务用阻塞重试。4. RedLock方案与争议边界极端场景到底能不能用前面讲的都是单节点Redis实现分布式锁。如果Redis是主从架构有一个问题会让人很不安客户端A在Master上拿到了锁但Master还没来得及把这个key同步给Slave就宕机了Slave被选举成新的Master此时客户端B也能在新Master上拿到同一把锁。这就出现了两个客户端同时持有锁的情况互斥性被打破。为了解决这个问题就有人提出了RedLock算法。4.1 RedLock算法的核心逻辑RedLock的思路是既然单个Redis节点不可靠那就向多个独立的Redis节点请求加锁只在大多数节点上都加锁成功才认为真正拿到了分布式锁。具体步骤大致是这样客户端向N个独立的Redis节点官方建议N5同时发送SET锁请求使用相同的key和value。计算加锁的耗时只有满足两个条件才算加锁成功超过N/21个节点加锁成功且总耗时小于锁的有效期。加锁成功后锁的有效期要减去加锁的耗时。释放锁时向所有节点发送DEL命令。这个算法就是为了让锁的持有方冗余化单个节点挂掉不影响整体。4.2 业界对RedLock的知名质疑RedLock一出来就引发了分布式系统领域的大讨论。某位专门研究分布式一致性的专家指出RedLock本质上是一个基于“时间假设”的方案它依赖所有Redis节点的时钟大致同步但现实世界里节点时钟可能发生跳跃一旦时钟回拨锁的有效期就会被错误计算导致多个客户端同时持有锁。Redis的作者则坚持RedLock在实践中是可用的反对意见更多是理论层面的极端场景。这场争论其实没有绝对结论但它给我们一个非常重要的启发Redis分布式锁是“高可用”方案不是“强一致”方案。如果你的业务在锁失效的极端情况下会产生资金损失或不可逆的后果那就要慎重。4.3 我的工程取舍建议在真实项目中我没有对RedLock完全迷信也不会完全否定它。我更倾向于按场景分情况处理常规业务场景比如接口防重、订单状态流转单节点Redis配上主从切换已经足够。即使锁出现短暂失效业务底层还有数据库唯一索引兜底。对并发正确性要求极高的场景比如库存扣减、账户扣款我建议在Redis锁之外再加一层数据库乐观锁或版本号校验做到“双保险”。单纯依赖任何一种分布式锁都不是绝对安全的做法。工程的参考系应该放在整个系统的链路上而不是锁本身。有个观点我想强调一下分布式锁只是并发控制的手段之一不是万能药。一个成熟的系统通常会在数据库层做唯一约束在服务层做分布式锁在资源侧做幂等设计三层叠加才能把并发问题控制住。5. 实战避坑指南这些问题我几乎都遇到过这一章我直接整理一个排查速查表都是实际生产环境里可能遇到的典型问题。问题现象根本原因解决方案拿到锁后执行完删除了别人的锁释放锁时没有判断value是否自己的用Lua脚本校验唯一标识后再删业务没跑完锁就过期了过期时间设置不合理未用看门狗使用Redisson默认看门狗或合理估算耗时同一线程进入两次加锁代码就死锁锁不可重入使用Redisson的可重入锁或自己用hash结构实现Master宕机后锁失效两个线程同时执行业务主从复制异步锁数据未同步接受短暂失效或引入RedLock或业务做幂等大量线程同时等待锁Redis CPU飙升自旋重试导致羊群效应控制重试频率用Redisson的等待机制代替自旋5.1 锁误删问题为什么这么隐蔽锁误删的经典场景是这样的线程A拿到锁因为GC停顿或网络延迟业务执行超过了锁的过期时间。此时锁自动释放线程B拿到锁开始执行。线程A缓过劲来执行完了在finally里执行DEL直接把线程B的锁删了。线程C又能拿到锁了。这就是为什么释放锁必须校验唯一标识的原因。用Lua脚本把“GET判断DEL删除”合并成原子操作能杜绝这个问题。但要注意误删锁的场景往往是你根本意识不到锁过期了的场景所以就算代码写得再严谨也要设计好业务对幂等性的容忍度。5.2 看门狗过期时间到底怎么调很多人问我Redisson的默认30秒会不会太长万一线程真的挂了其他线程不是要等30秒吗实际测试下来Redisson的30秒设计是有道理的。它配合10秒轮询续期能让锁在正常业务下无限续期同时把异常场景下的等待时间控制在可接受范围内。如果你觉得30秒太久可以通过Config修改lockWatchdogTimeout参数但我一般不建议调到10秒以下否则网络抖动一次就可能续期失败锁提前释放。5.3 如何测试Redis分布式锁的可靠性测试分布式锁常规的JUnit单元测试根本测不出问题必须上并发压测模拟多线程抢占。我提供一个思路搭建两个应用实例指向同一个Redis模拟集群环境。写一个并发任务每轮任务都执行“加锁、睡眠500毫秒模拟业务、解锁”。用一个计数器统计同时进入临界区的线程数量理论上任何时刻这个计数器的值都不能超过1。测试过程中手动重启一个实例或者用kill -9模拟宕机观察锁能否正常释放。我踩过最深的坑是单机测试一切正常上了集群就出问题。所以分布式锁的测试环境一定要接近生产环境至少要让多实例同时跑。5.4 加锁Key设计的统一规范最后提一个工程上的细节。锁Key的命名规范非常重要我见过很多团队因为Key命名混乱导致出了bug都无从排查。建议统一格式业务场景:资源类型:资源ID。比如order:pay:123456 coupon:use:888888 inventory:deduct:SKU1001这样既方便定位哪把锁出了问题也能在Redis客户端里按前缀搜索到所有锁对监控和排查都有帮助。命名规范这种东西看起来不起眼关键时刻能省下大把排障时间。5.5 如何监控分布式锁的健康状况线上环境最好把锁的获取耗时、等待时间、锁冲突次数这几个指标暴露出来。Redisson通过RLock本身没有现成的监控指标但你可以封装一层自己的锁工具类在加锁成功和失败的地方加上日志或埋点。我一般会记录三个数据点加锁等待时间、锁冲突次数、锁自动过期次数。锁自动过期次数尤其重要它间接反映了你设置的过期时间是不是合理或者业务是不是有慢查询。如果这个数字持续增长说明有线程频繁在锁过期后才完成业务这是严重的并发隐患。结尾的实操心得根据我个人在实际项目里的使用经验Redis分布式锁最推荐的落地方式就是优先使用Redisson不要自己造轮子业务侧配合幂等设计不要把锁当作唯一的并发防线锁粒度尽量小能按订单就按订单不要搞全局锁。有一个细节想单独提一下因为我一开始就栽在这里在Spring中如果RedissonClient是单例注入千万不要手动去关闭它。很多人习惯在方法结束的时候调用redissonClient.shutdown()导致后续所有请求都拿不到客户端报各种连接异常。RedissonClient的生命周期应该跟随应用不是跟随请求。Redis分布式锁这个话题每次深入一层都有新收获。从SETNX一把梭到理解看门狗、RedLock的局限这个过程本身就是对分布式系统认知的提升。如果你也在用Redis做分布式锁建议把这篇文章里的几个场景自己动手复现一遍特别是并发测试和切换时钟的例子。踩过这些坑之后你才算真正理解了这把“锁”。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
