2. 为什么单机锁在分布式环境下失效了很多同学第一次接触分布式锁脑子里都会冒出一个疑问我在单机项目里用synchronized或者ReentrantLock用得好好的为什么到了分布式环境就不行了道理其实很简单。synchronized锁住的是 JVM 进程内的对象监视器多个线程共享同一个 JVM 内存锁自然能互斥。但在分布式架构下服务往往部署成多实例请求会通过负载均衡分散到不同的机器上。此时 A 机器上的线程拿到了锁B 机器上的线程根本感知不到这把锁的存在——因为 JVM 内存是隔离的锁信息无法跨进程传递。这就带来一个经典的多实例并发写问题。比如电商系统的库存扣减服务部署了 3 个实例同时收到 5 个下单请求每个实例都认为库存是自己的本地变量各自扣减自己内存里的数值最终数据库里的库存可能被扣成负数或者出现超卖。用技术术语说这叫并发安全失效——单机锁的保护边界只到进程为止跨进程就需要一把“全局可见”的锁。既然 JVM 锁不行那数据库锁行不行MySQL 的行锁、表锁确实可以做到跨进程互斥但性能瓶颈很明显高并发场景下数据库的连接池、锁等待、事务开销都会成为新的热点。而且数据库锁的释放逻辑往往很重一旦事务持有锁的时间过长很容易拖垮整个数据库。所以在纯高并发场景下大家更倾向于引入一个轻量级的中间件来承担锁的职责——Redis 就是在这个背景下被选中了。Redis 能成为分布式锁的主流载体主要有三个核心优势单线程模型Redis 的命令执行是串行的多个客户端同时写同一个 key 时天然不会出现并发竞争导致的数据错乱这是实现互斥的底层保障。高性能纯内存操作单机 QPS 可以轻松到十万级别锁的获取和释放都是微秒级延迟不会成为业务瓶颈。丰富的数据结构与原子操作SETNX、SET EX、Lua 脚本、Redisson 封装都提供了非常成熟的原子化工具可以保证锁操作的完整性和安全性。我记得自己第一次在项目里引入 Redis 分布式锁就是因为订单服务的并发量上来了数据库行锁压不住接二连三出了好几个超卖事故。当时踩了不少坑也走了不少弯路。这篇文章我就把整套思路整理出来——从最基础的锁实现讲起逐步过渡到 Redisson 高级封装、RedLock 理论、常见的坑和排查思路尽量做到一篇讲透。如果你正在做微服务改造或者系统并发量开始抬头这篇文章应该能帮你节省不少试错时间。3. 最基础的 Redis 分布式锁长什么样3.1 加锁SETNX 与过期时间的正确姿态最初级的分布式锁实现思路就是利用 Redis 的SETNX命令——如果 key 不存在则设置成功返回 1如果 key 已存在则设置失败返回 0。这个特性天然适合做互斥锁。SETNX lock:order 1返回 1 表示加锁成功返回 0 表示锁已被别人持有。但这里有一个非常经典的问题如果客户端加锁成功后业务代码执行到一半崩了或者机器宕机、网络断开lock:order这个 key 永远不会被删除锁就永久死锁了——其他所有客户端都会永远等不到锁。所以加锁的第二个关键点是必须设置过期时间。Redis 从 2.6.12 版本开始SET命令支持NX和EX参数组合可以一条命令完成“不存在才设置 过期时间”两个操作SET lock:order 1 NX EX 30这条命令的意思是只有当lock:order不存在时才写入写入后 30 秒自动过期。注意这里必须用一条命令完成不能先SETNX再EXPIRE。如果拆成两条命令就会有一个时间窗口第一条命令执行完第二条命令还没执行时客户端崩了——锁同样会永久存在。这在并发场景下是致命的。注意很多老教程会让你用SETNXEXPIRE的组合这是典型的错误示范。务必使用SET ... NX EX一条命令完成。3.2 释放锁为什么不能直接 DEL加锁解决了释放锁同样有讲究。很多人第一反应是业务执行完了直接DEL lock:order删掉 key 不就行了如果锁的持有者永远是同一个客户端那确实没问题。但分布式锁的持有者可能随时变化。举个例子客户端 A 拿到锁执行业务代码结果业务卡了很久超过了 30 秒的过期时间。此时 Redis 自动把锁删除了。客户端 B 紧接着拿到了锁开始执行业务。这时候客户端 A 终于恢复过来执行完业务顺手一个DEL lock:order——它删掉了 B 的锁B 的临界区瞬间失去了保护后面的并发请求就能同时进入数据安全直接崩塌。正确做法是释放锁之前先校验这个锁是不是自己加的。具体做法是加锁时设置一个唯一标识比如 UUID释放时用 Lua 脚本原子地完成“比对 删除”if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end这段脚本的意思是先取锁值如果等于客户端自己的唯一标识才删除如果不等说明锁已经被别人持有或已经过期不执行删除。用 Lua 的原因是保证校验和删除两个操作的原子性避免中间被其他命令插队。3.3 一个完整的初级锁实现Java 示例用 Java 的StringRedisTemplate可以很轻量地把上面的逻辑写出来public class SimpleRedisLock { private StringRedisTemplate redisTemplate; public boolean tryLock(String key, String requestId, int expireSeconds) { // 加锁key 不存在才设置设置成功后过期 Boolean result redisTemplate.opsForValue() .setIfAbsent(key, requestId, expireSeconds, TimeUnit.SECONDS); return Boolean.TRUE.equals(result); } public boolean unlock(String key, String requestId) { // 释放锁比对唯一标识后删除 String script if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; Long result redisTemplate.execute( new DefaultRedisScript(script, Long.class), Collections.singletonList(key), requestId ); return Long.valueOf(1).equals(result); } }其中requestId就是客户端唯一的标识通常用UUID.randomUUID().toString()生成。加锁时带上释放时校验缺一不可。这套实现能解决 80% 的基础场景但它有一个隐藏弱点如果业务执行时间超过锁的过期时间锁自动释放了别的客户端就会趁虚而入。而且过期时间很难拍脑袋定——设短了业务没执行完锁就失效了设长了万一客户端永久宕机锁要等很久才能被回收。这个问题恰恰是后面 Redisson 要解决的。4. 锁续期与 Redisson——把分布式锁做成生产级4.1 看门狗机制锁自动续期的底层逻辑前面说到固定过期时间的锁有个尴尬场景你预估业务要执行 3 秒设了 10 秒过期结果业务因为网络抖动、慢查询跑了 20 秒——锁在第 10 秒就没了临界区洞开。而且这个时间很难预估因为业务方法的耗时不是恒定值数据库抖动、下游接口变慢都会让执行时间拉长。Redisson 的解决方案是看门狗机制。看门狗本质上是一个后台定时任务默认每 10 秒执行一次检查当前客户端是否仍持有锁如果持有就把锁的过期时间重置为 30 秒。这样一来只要持有锁的客户端进程活着锁就会一直续期不会因为业务耗时过长而自动释放。听起来很完美但有一个前提必须搞清楚看门狗只在客户端进程正常存活时运作。如果客户端宕机了、进程被强杀了看门狗线程也会随之消失锁失去续期能力最终在 30 秒后自动过期释放。这个设计既保证了“持有者死了锁能回收”又避免了“业务活着锁被误删”的问题。补充一个容易被忽略的点Redisson 的看门狗默认是全局的默认锁超时时间是 30 秒每 10 秒续期一次。如果你设置的锁超时时间小于 30 秒看门狗不会生效锁会在你指定的时间后直接过期。4.2 Redisson 加锁流程拆解Redisson 的RLock使用起来非常简洁但它的内部流程比我们想象中要复杂得多。核心加锁过程的简化流程大致如下客户端向 Redis 发送加锁命令锁 key 的结构是一个 Hashfield 是客户端唯一标识 线程 IDvalue 是重入计数。如果 key 不存在执行加锁设置 Hash 数据并启动看门狗定时续期。如果 key 已存在检查 hash 中的 field 是否为当前客户端——如果是重入计数加 1如果不是说明锁被别人持有返回剩余过期时间。客户端根据返回的剩余时间决定是否自旋等待。Redisson 默认会循环尝试获取锁直到超时。这里有个非常实用的特性可重入。同一个客户端线程可以多次获取同一把锁。为什么需要重入因为业务代码里经常出现嵌套调用的情况A 方法加了锁A 方法内部又调用了同样加了同一把锁的 B 方法。如果没有重入机制B 方法会发现锁已被持有把自己给锁死了。Redisson 通过对 hash 字段的计数实现重入每次获取锁计数加一每次释放锁计数减一只有计数归零才真正删除锁。4.3 生产级代码模板实际项目中接入 Redisson 非常简单。先引入依赖dependency groupIdorg.redisson/groupId artifactIdredisson-spring-boot-starter/artifactId version3.17.7/version /dependency然后获取并使用锁Autowired private RedissonClient redissonClient; public void processOrder(Long orderId) { RLock lock redissonClient.getLock(lock:order: orderId); try { // 尝试加锁最多等待 5 秒加锁后 30 秒自动过期看门狗会续期 boolean isLocked lock.tryLock(5, 30, TimeUnit.SECONDS); if (!isLocked) { throw new RuntimeException(系统繁忙请稍后重试); } // 业务逻辑 doProcessOrder(orderId); } catch (InterruptedException e) { Thread.currentThread().interrupt(); throw new RuntimeException(获取锁被中断, e); } finally { // 必须保证锁能释放 if (lock.isHeldByCurrentThread()) { lock.unlock(); } } }注意tryLock的三个参数第一个是获取锁的最大等待时间第二个是锁的自动过期时间leaseTime第三个是时间单位。当leaseTime不传或传 -1 时Redisson 会启动看门狗自动续期手动传入时看门狗不生效锁在指定时间后强制过期。这里还有一个个人建议finally里释放锁之前最好判断一下isHeldByCurrentThread()。为什么因为如果锁已经因为某种原因过期了或者被别的线程意外释放了在当前线程再去unlock会抛出IllegalMonitorStateException。加上这个判断能让释锁逻辑更健壮线上少一些异常告警。5. RedLock 到底在解决什么问题5.1 单节点锁的致命隐患前面说到的所有实现都是基于单个 Redis 节点。单节点看似没问题但在主从架构下有一个隐藏很深的坑。Redis 主从复制是异步的——主节点写入数据后会立即返回客户端成功后台再异步同步到从节点。如果客户端 A 在主节点上加锁成功主节点还没来得及把锁数据同步到从节点主节点就宕机了。此时哨兵把从节点提升为新的主节点。但新主节点上并没有这把锁的数据。客户端 B 就能轻而易举地在新的主节点上加锁成功——于是 A 和 B 同时持有锁分布式锁形同虚设。这种情况概率不高但一旦发生就是严重的数据一致性事故。在金钱交易、库存扣减等场景里这种低概率事件是不能接受的。Ruby 的作者 SalvatoreAntirez提出的 RedLock 算法就是为了解决这种单点故障——用多个独立的 Redis 节点让锁的可靠性不依赖单个节点。5.2 RedLock 算法核心步骤RedLock 的思路其实不复杂核心步骤如下客户端获取当前系统时间记为 T0。依次向 N 个独立的 Redis 节点官方建议 N5发送加锁请求。每个请求设置一个较短的超时时间比如 50ms——如果某个节点无响应立即切换到下一个节点不浪费时间。只有当客户端在超过半数节点N/21上成功加锁并且总耗时小于锁的有效时间时才算加锁成功。加锁成功后锁的有效时间 预设锁有效期 - 加锁总耗时。释放锁时向所有节点发送释放锁的 Lua 脚本无论之前是否加锁成功每个节点都要释放。这里最核心的指标是“超过半数”。只要 5 个节点中至少 3 个存活客户端就能成功加锁即使有 2 个节点挂了也不影响。而在主从同步中只要至少 3 个节点确认了锁的存在即使其中 1 个节点在确认后宕机锁的信息也仍然存在于其他 2 个节点中新客户端就无法获得多数派支持锁的安全性达到了“少数节点故障不破坏互斥”的效果。5.3 关于 RedLock 的争议与取舍RedLock 自 2015 年提出以来一直存在学术争议。Martin Kleppmann《Designing Data-Intensive Applications》作者专门写过一篇文章批评 RedLock认为它依赖系统时钟而分布式环境下的时钟可能会发生跳跃NTP 调整、虚拟机时钟漂移会导致锁的安全边界被破坏。Antirez 也专门发文回应争论的核心在于对“安全性”边界的定义。我的个人看法是如果你的系统并发量还没到每秒几万甚至更高且你们有可控的网络环境、准同步的系统时钟RedLock 的工程价值是大于其理论缺陷的。真正落地时要注意两点节点的独立性这 5 个 Redis 必须是完全独立的不能共享物理机、虚拟机宿主机、网络交换机否则就没有真正隔离故障域。重试要谨慎获取锁失败后建议加一个随机延迟再重试避免多个客户端同时重试形成“惊群效应”把节点打满。如果你的系统要求的是强一致性而且不想背负 RedLock 的复杂度另一个思路是直接用 ZooKeeper 的临时顺序节点来实现分布式锁。ZK 的锁模型天然支持监听与有序等待且其线性一致性保证比 Redis 的“多数派”方案更严格代价是性能远低于 Redis。选型时要在性能和一致性之间做取舍没有免费的午餐。6. 实战场景库存扣减并发治理6.1 原始代码的问题纸上谈兵再多不如看一段实际代码。下面是一个典型的库存扣减接口我见过很多项目第一版都是这样写的public boolean deductStock(Long skuId, Integer count) { Stock stock stockMapper.selectBySkuId(skuId); if (stock.getStock() count) { return false; } // 模拟耗时操作 Thread.sleep(50); stock.setStock(stock.getStock() - count); stockMapper.updateById(stock); return true; }这段代码在单机环境下只要在方法上加synchronized就勉强能用。但到了多实例部署就彻底失控了——两个实例同时读到库存是 10同时扣减 5最终库存从 10 变成 5而不是正确的 0。为什么会这样因为每个实例的 JVM 内存里各有一份 stock 对象互不可见。有些同学会想把库存查询和扣减放到一个数据库事务里用SELECT ... FOR UPDATE锁行。这样做确实能保证正确性但数据库行锁在高并发下会成为性能瓶颈——锁等待、死锁检测、连接池竞争任何一个都能让接口的 P99 延迟飙升。在秒杀等场景下这种方案会直接把数据库拖垮。6.2 引入分布式锁后的正确姿势引入 Redis 分布式锁后库存扣减接口可以这样改造public boolean deductStock(Long skuId, Integer count) { String lockKey lock:stock: skuId; RLock lock redissonClient.getLock(lockKey); boolean isLocked false; try { // 最多等待 3 秒获取不到就快速失败 isLocked lock.tryLock(3, TimeUnit.SECONDS); if (!isLocked) { return false; // 系统繁忙直接告知失败 } // 加锁成功后再执行查询、判断、扣减 Stock stock stockMapper.selectBySkuId(skuId); if (stock.getStock() count) { return false; } stock.setStock(stock.getStock() - count); stockMapper.updateById(stock); return true; } catch (InterruptedException e) { Thread.currentThread().interrupt(); return false; } finally { if (isLocked) { lock.unlock(); } } }这里有个细节锁的粒度是skuId也就是每个商品一把锁而不是整个服务一把全局锁。为什么这么设计因为不同商品的库存是独立的互不影响用全局锁会白白降低并发能力。比如 100 个商品同时被抢购如果只有一把全局锁那所有商品的扣减操作都串行执行按 skuId 加锁后100 个商品可以并行扣减互不干扰。再看上面代码中“先查后写”的逻辑加锁后库存查询、判断、扣减、更新的整个过程都在锁的保护范围内不会出现读到过期数据的情况。和数据库行锁方案对比Redis 锁释放后其他线程立刻能进入等待时间短得多数据库的压力也不会被锁放大。6.3 锁的粒度选择越细越好吗锁粒度是一个经常会纠结的问题。拿上面的库存案例来说按skuId加锁已经比较细了但有些人会想要是同一个商品有 10 个规格颜色、尺码不同规格的库存也是独立的是不是可以按skuId 规格ID加锁理论上确实可以进一步细分但锁粒度越细锁的数量越多Redis 里保存的锁 key 数量也会增多。如果你的商品量级是百万级甚至千万级每个商品都可能在任意时刻被抢购锁 key 的生命周期虽然短但 Redis 的内存和连接管理压力会上升。我的建议是锁粒度细到什么程度取决于业务上的“临界资源”是否独立。如果两个请求操作的数据完全无关比如不同 sku 的库存就完全可以用不同的锁如果它们最终会写同一个数据库行就不能因为“代码上看着不相关”而拆开。判断标准很简单——扣减后影响的数据库行是否可能冲突。冲突面在哪锁就得覆盖到哪。7. 常见坑与排障速查表7.1 我踩过的几个典型问题先分享一个我真实遇到过的问题。有一段时间订单服务的分布式锁偶尔会失效表现为两个线程同时进去了。排查了很久最后发现原因很简单我们的订单服务是通过 Lua 脚本手动实现加锁的Lua 脚本里设置 key 时用了SETNX但后面补了一个EXPIRE两条命令不是原子的。在高并发下SETNX执行成功后当前线程被 GC 停顿了 100msEXPIRE还没执行就发生了上下文切换这时另一个线程直接SETNX成功——两把锁同时存在。虽然概率不高但一旦发生就是事故。这个问题的根因就是前面讲的加锁必须一条命令完成不能拆开。第二个问题是关于锁自动续期导致锁无法释放。当时我用了 Redisson 的看门狗机制默认锁超时 30 秒。结果有一个慢 SQL 偶尔要跑 40 秒正常情况下超过 30 秒后锁会被自动释放不会有问题。但因为看门狗的存在锁被一直续期直到 SQL 执行完才释放。这就意味着如果 SQL 卡死了锁会一直被续期到天荒地老其他线程永远等不到锁。所以看门狗也不是万能药——业务时间特别长的场景要么合理设置 leaseTime要么给业务方法设置单独的 watchdog 超时控制。第三个问题是在 finally 中无条件释放锁。如果业务里抛出的异常导致锁提前过期而此时别的线程已经拿到了锁当前线程在 finally 里执行unlock()会直接删除别人持有的锁。加上isHeldByCurrentThread()的判断能避免这种“误杀”。7.2 排障速查表日常排查分布式锁问题时我习惯参考下面这张速查表现象可能原因排查思路两个线程同时进入临界区锁 key 未设置过期时间或设置方式非原子检查加锁命令是否SET NX EX一条命令完成锁永远无法获取持有者宕机且锁无过期时间检查锁是否设置了过期时间看门狗是否合理偶发性线程阻塞、接口超时锁竞争激烈等待时间太长检查锁粒度是否过粗能否按业务维度拆细锁释放报IllegalMonitorStateException锁已被其他线程释放或过期释放前用isHeldByCurrentThread()判断主从切换后锁丢失主从异步复制导致锁数据未同步引入 RedLock或改用 ZooKeeper 实现锁续期时间长导致无法释放看门狗持续续期业务卡死为业务方法设置独立的执行超时7.3 实用避坑技巧汇总最后把这几年的经验浓缩成几条直接给你抄作业用锁的过期时间不是拍脑袋定的。如果不用看门狗leaseTime 一般建议设为慢业务平均耗时的 5~10 倍并留足余量。但也不要无限长——太长的过期时间会让宕机后的锁回收变慢影响可用性。锁等待时间要短。tryLock的等待时间建议控制在 1~5 秒内超过这个时间就返回失败让用户重试或提示系统繁忙避免大量线程堆积等待。锁的 key 必须有业务语义。用lock:stock:skuId这样的格式方便线上排查。锁 key 散落在 Redis 里的时候一眼能看出是哪个业务、哪个资源。监控不能少。分布式锁的获取耗时、释放耗时、获取失败率都应该埋点上报。尤其是获取失败率突然飙升往往意味着某个资源被锁死了提前发现总比事故后补救强。不要用分布式锁去替代数据库的唯一约束。锁机制只负责控制并发访问最终的幂等校验、防重校验还是要靠数据库的唯一索引兜底。锁是第一道防线数据库约束是最后一道防线两道都上才稳妥。踩过几次坑之后我最大的体会是分布式锁的难点不在于“怎么用”而在于“出了问题时怎么快速定位”。把前面这些细节都处理好再配合好监控和日志线上稳定性就能上一个台阶。希望这篇笔记能帮你在分布式锁这条路上走得顺一些。