1. 集群环境下的并发困局：为什么单机锁不够用了

我最早接触分布式锁，是在一个很尴尬的场景里摔过跟头。当时服务已经上了集群，两个节点同时跑定时任务，结果数据库里出现了一堆重复的优惠券发放记录。排查的时候第一反应是代码写错了，看了半天发现逻辑完全没问题——问题出在传统的Lock也好、synchronized也好，它们都只对单个JVM进程内的线程生效。节点A的锁，节点B根本感知不到，两个进程各自为政，并发请求自然就穿透了。

说白了，单机锁解决的是"线程竞争"，分布式锁解决的是"进程竞争"。在集群架构下，多个服务实例处理同一份业务数据时，必须有一个所有实例都能访问的公共协调者，谁抢到了这个协调者发下来的"令牌"，谁才有资格执行业务逻辑，其他实例只能等待或者放弃。

Redis做这个协调者，是目前最主流的方案之一。原因也很直白：Redis本身是集群部署的，天然具备高可用能力，SET命令配合过期时间可以原子地写入一个唯一标识，性能极高，单实例的读写能力能到十万级QPS，而且几乎所有后端团队都已经在运维Redis，不需要额外引入一套ZooKeeper或者etcd的部署成本。

不过这里得先泼一盆冷水：Redis分布式锁不是简单写个SETNX就完事的，它的正确性依赖很多边界条件的处理。网上流传的很多"Redis分布式锁教程"只讲了加锁和解锁，漏掉了过期时间设置、锁误删、可重入、集群主从切换等关键细节，生产环境跑起来大概率要出事。这篇文章我结合自己实际改造过的项目，把从原理到落地的完整链路讲清楚，特别是那些坑，看完能帮你省不少麻烦。

2. 锁的本质与Redis实现原理：从单机锁到分布式锁的演进思路

2.1 一把锁到底在锁什么

要理解分布式锁，先得搞清楚锁的本质。锁的核心作用不是拦住所有代码执行，而是保护一段"临界区"——也就是多个线程同时访问共享资源时，可能产生数据不一致的那段代码。比如库存扣减、订单状态流转、优惠券核销，这些操作如果没锁保护，两个请求同时读到库存为1，各自扣减后写回，库存就变成0而不是-1，业务数据就错了。

在单机环境下，这个协调工作由JVM完成：线程A拿到锁，线程B就在synchronized的monitor上阻塞等待，JVM保证同一个时刻只有一个线程能进入临界区。这是通过操作系统的线程调度和内存屏障实现的，粒度精确到进程内部。

但集群环境下，两个服务实例跑在完全不同的JVM里，它们的内存空间相互隔离，谁也不知道对方是不是正在执行同一段逻辑。这时候需要一把"大家都能看见的锁"——锁的状态必须存放在一个所有实例都能访问的公共存储中。谁在这份公共存储里写入了"我已加锁"的状态，谁就获得执行权，执行完再清除这个状态。这就是分布式锁的基本模型。

Redis在这个模型里充当的就是那个公共存储。SET key value NX PX expiry命令能实现"原子地检查并写入"：NX参数保证只有key不存在时才能写入成功，这对应"互斥获取"；PX参数给key设置过期时间，对应"锁的自动释放"，防止持有锁的服务挂了导致死锁；value存一个唯一标识，对应"锁的持有者身份"，解锁时用来校验防止误删。这一条命令就把分布式锁最核心的骨架搭出来了。

2.2 SETNX的演变：从两步操作到原子指令

很多老教程里还在用SETNX加锁、EXPIRE设置过期时间的组合写法：

SETNX lock_key unique_value EXPIRE lock_key 30

这个写法在面试里基本是送命题——如果SETNX执行成功后、EXPIRE执行前，服务实例突然宕机，锁的过期时间就永远设置不上，这把锁就变成了"永久锁"，所有后续请求全部卡死。这就是典型的非原子操作带来的问题。

Redis 2.6.12版本之后提供了一个解决这个问题的方案，就是前面提到的单条原子命令：

SET lock_key unique_value NX PX 30000

一条命令完成"不存在才写入"和"设置过期时间"两个操作，Redis服务端保证它们的原子性。这也是目前实现Redis分布式锁的基础指令，理解这一点，后面所有的实现方案都是在这条命令之上做扩展。

我自己的习惯是，给锁的value生成一个UUID + 线程ID + 时间戳的组合字符串，或者直接用UUID.randomUUID().toString()，保证全局唯一即可。这个唯一值是为了"解锁时验明正身"，后面详说。

2.3 为什么需要看门狗：过期时间引发的两难

给锁设置过期时间，本质上是个两难问题：过期时间设短了，业务还没执行完锁就被自动释放，其他请求趁虚而入，临界区被并发进入；设长了，一旦持有锁的服务宕机，其他请求就要白白等待很久才能接管。而且业务执行时间本身是个变量，有时快有时慢，一个固定值很难匹配所有场景。

业界通用的解法是"续期"机制，也就是Redisson实现的看门狗（Watch Dog）。简单说，当你加锁成功后，后台会启动一个定时任务，每隔锁超时时间的三分之一（Redisson默认锁超时30秒，就是每10秒）检查一次：如果锁还在持有中，就自动把过期时间重置为30秒。业务执行多久，锁就续期多久，既不会提前失效，也能在持有者宕机时通过过期机制兜底。

看门狗的作用非常关键，它解决的是"锁的生命周期必须覆盖业务执行周期"这个根本问题。后面讲Redisson实现的时候，我会给出更详细的参数说明。

3. 三种主流的Redis分布式锁实现方案对比

3.1 方案一：纯Redis命令手写锁（适合学习与轻量场景）

最快的落地方式就是用Spring Data Redis或Lettuce的API，直接封装一个最简分布式锁：

// 加锁 String lockKey = "lock:order:" + orderId; String requestId = UUID.randomUUID().toString(); Boolean locked = redisTemplate.opsForValue() .setIfAbsent(lockKey, requestId, 30, TimeUnit.SECONDS); // 业务逻辑 if (Boolean.TRUE.equals(locked)) { try { // 执行临界区业务 } finally { // 解锁：使用Lua脚本保证原子性 String script = "if redis.call('get',KEYS[1]) == ARGV[1] then " + "return redis.call('del',KEYS[1]) else return 0 end"; redisTemplate.execute(new DefaultRedisScript<Long>(script, Long.class), Arrays.asList(lockKey), requestId); } }

这个方案的优点是零依赖、代码透明，你能控制每一个细节。缺点是以下能力需要自己逐一实现：可重入（同一线程重复获取锁）、看门狗续期、公平等待（抢不到锁的请求怎么排队退避）。如果只是学习原理，或者业务场景非常简单，可以先用这个方案跑通；生产环境强依赖的话，我建议往下看Redisson。

解锁环节为什么一定要用Lua脚本，这里多说一句。解锁其实是两步：先GET对比value是否自己的标识，再DEL删除key。如果分开执行，中间可能发生"锁已经到了过期时间被自动释放，另一个请求重新加锁成功"，然后你的DEL删的是别人的锁——这就是经典的"误删锁"问题。用Lua脚本把两步操作交到Redis服务端原子执行，才能保证"只有持有者本人能解锁"。

3.2 方案二：Redisson的RLock（生产环境首选）

Redisson是Java生态里最成熟的Redis分布式锁客户端，它把上面说的看门狗续期、可重入、公平锁、红锁等都封装好了。核心用法简单到离谱：

RLock lock = redissonClient.getLock("lock:order:" + orderId); boolean locked = false; try { locked = lock.tryLock(2, 30, TimeUnit.SECONDS); if (locked) { // 执行业务逻辑 } } finally { if (locked && lock.isHeldByCurrentThread()) { lock.unlock(); } }

tryLock的三个参数分别是：等待获取锁的最大时间（拿不到锁就放弃，避免无限阻塞）、锁的自动过期时间、时间单位。这里有个容易踩的坑：如果你不传过期时间，Redisson会启用默认30秒的看门狗方案，锁会自动续期直到unlock；如果你手动传了过期时间，看门狗就不生效，锁到时间自动释放。所以传参前要想清楚业务的最大执行时长，别随手填个数字。

Redisson是用Lua脚本实现的原子加锁和解锁，内部数据结构用的是Redis的Hash，而不是简单的String。这也是它支持可重入的关键：同一个线程重复加锁时，Hash里对应字段的计数加一，解锁时减一，计数归零才真正删除key，和ReentrantLock的计数思路完全一致。

3.3 方案三：RedLock——高安全场景才需要的"红锁"

Redisson的RLock虽然好用，但它有一个隐患：主从切换下可能丢失锁。场景是这样的：锁写入master节点，master还没来得及同步到slave，master宕机，slave被提升为新的master，但新master上并没有这把锁的数据，其他请求就能顺利加锁成功——锁的互斥性在故障瞬间被破坏了。

Redis官方给出的应对方案是RedLock，思路是"少数服从多数"：同时向多个独立的Redis节点（官方要求至少5个，且相互之间没有主从关系）执行加锁操作，只有成功加锁超过半数节点（如5个中至少3个），才认为加锁成功；释放锁时向所有节点发送解锁命令。

RedLock的代价是明显的：需要额外部署多套Redis实例，运维复杂度翻倍；加锁时间变成多次网络通信的累加，性能下降；而且在极端情况下依然存在理论上的安全窗口。所以我的判断是：如果你的业务允许偶尔的重复执行（比如幂等性设计做得好），用法案二足够；如果业务绝对不能容忍并发穿透（比如分布式事务中的资源冻结），再考虑RedLock。绝大部分互联网业务场景，其实不至于走到RedLock这一步——系统架构先保证Redis集群本身的高可用，比纠结RedLock的极端场景更实际。

4. 实战案例：集群环境下订单并发扣减库存的完整实现

4.1 场景设定与代码骨架

为了把原理落到实地，我以一个最常见的"并发扣减库存"场景为例。假设我们有3个后端服务实例（对应3个JVM进程），它们共享同一个Redis集群和一个MySQL库存表。用户疯狂点击下单时，请求被负载均衡分发到不同实例上，同一个商品ID的扣减请求可能同时落在不同实例上。目标：同一时刻，只有一个请求线程能真正执行"库存扣减+生成订单"这段逻辑。

核心代码结构如下：

@Service public class StockService { @Autowired private RedissonClient redissonClient; @Autowired private StockMapper stockMapper; public OrderResult deductStock(Long productId, Integer quantity) { // 以productId作为锁的粒度，不同商品的请求互不阻塞 String lockKey = "lock:stock:" + productId; RLock lock = redissonClient.getLock(lockKey); boolean locked = false; try { // 最多等待3秒获取锁；获取成功后锁的自动过期时间由看门狗持续续期 locked = lock.tryLock(3, TimeUnit.SECONDS); if (!locked) { // 没拿到锁，返回繁忙标记，提示用户稍后重试 return OrderResult.busy(); } // 1. 查询当前库存 Stock stock = stockMapper.selectByProductId(productId); // 2. 校验库存是否充足（业务规则） if (stock.getAvailableStock() < quantity) { return OrderResult.noStock(); } // 3. 扣减库存：使用乐观锁版本号防止脏写 int updated = stockMapper.deductStock(productId, quantity, stock.getVersion()); if (updated == 0) { return OrderResult.retry(); } // 4. 生成订单（从略） return OrderResult.success(); } finally { // 释放锁前判断当前线程是否还持有锁，防止误释放 if (locked && lock.isHeldByCurrentThread()) { lock.unlock(); } } } }

注意几个细节。第一，锁的粒度按productId细分，而不是用一把全局锁，这样不同商品的并发请求可以并行处理，避免互相拖累，大幅提升系统吞吐量，这也是面试里常考的一个优化点——锁的粒度越细，并发能力越强。第二，tryLock设置了最大等待时间3秒，防止某个请求一直等锁导致线程堆积。第三，释放锁前用isHeldByCurrentThread()做了复核，这个检查能避免一种隐蔽的问题：因为看门狗续期的存在，理论上锁不会在业务执行中被释放，但万一业务耗时极长，锁到期后又被别人获取，当前线程unlock就会删掉别人的锁——这个判断可以有效规避。

4.2 幂等性兜底：锁不是万能的

分布式锁并不能保证整个业务流程完美无瑕，它只能保证"互斥进入临界区"。一个很多新手容易忽略的问题是：业务执行过程中如果出现异常，导致部分数据写入了但事务没提交成功，重试的时候怎么办？

比如上面的扣减库存，第一步执行了"查询库存"、"扣减库存"，但第二步"生成订单"抛了异常，数据库事务回滚，库存恢复。如果客户端收到异常后立刻重试，一切正常。但如果重试是另一个实例发起，而业务处理中调用了外部接口（比如调用支付网关）——这个外部调用可能已经成功但响应丢失，重试就会造成重复扣款。

所以实践中的原则是：锁保证并发互斥，幂等设计保证业务正确，两者缺一不可。具体到库存扣减场景，我会在订单表上加业务唯一索引（比如orderNo），重复插入时报错直接返回"重复提交"；对外部接口调用，则要求接口本身支持幂等，传入预生成的唯一请求ID。

4.3 锁超时与业务超长的实战权衡

我在生产环境遇到过一次非常典型的锁超时事故。当时业务里有一段逻辑要批量刷新大量缓存，耗时通常只要2秒，但因为某次上游依赖服务响应极慢，这段逻辑整整跑了45秒。而我配置的锁过期时间是30秒，锁在第30秒自动释放了，第二个请求立刻进来拿到新锁，两个线程同时进入了临界区。

这类问题的排查思路是：先看监控，确认临界区代码的P99耗时；再把锁的过期时间设置为P99耗时的3到5倍，给足冗余；最好启用Redisson的看门狗让锁自动续期，避免写死一个固定值。Redisson默认看门狗每10秒续期一次（锁超时30秒的三分之一），这意味着业务执行时间超过30秒也不用担心锁提前失效。

不过也要注意，看门狗有个前提：持有锁的客户端进程还活着。如果进程因为Full GC长时间STW（Stop The World，JVM暂停所有线程的垃圾回收过程，可能持续数秒），看门狗线程也被暂停，锁到期后照样释放。极端情况下，GC导致的锁提前释放依然无法完全避免。真要彻底解决，得引入数据库事务或分布式事务中间件做二次校验，这也是为什么我说"锁不是银弹"。

5. 从单体到集群再到高可用：锁方案的演进路线

5.1 单机Redis vs 主从架构 vs 哨兵模式

分布式锁的可靠性，和底层Redis架构强相关。我用一个表格把常见部署形态对锁的影响说清楚：

这里要特别澄清一个误区：很多人以为用了Redis Cluster集群就可以高枕无忧了，但实际上Cluster的分片主从切换，和主从架构一样存在同步窗口问题。锁的key属于某一个分片，分片的主节点宕机后，如果锁数据尚未同步到从节点，新的主节点上就没有这个key，互斥性在故障切换的瞬间被打破。这是CAP理论中可用性和一致性冲突的体现——Redis优先保证了可用性，牺牲了强一致性。

5.2 based on your业务形态，怎么选最合适

技术选型没有绝对的最好，只有最合适。结合我自己的项目经验，给一个比较务实的决策路径：

• 如果业务量级不大（QPS几百），Redis主从+哨兵已经够用，锁的丢失概率极低，配合业务幂等设计完全可以接受。
• 如果是订单、支付、库存这类核心交易链路，我建议：用Redisson的RLock + 业务唯一约束 + 数据库乐观锁，三层防线叠加，而不是只依赖分布式锁。
• 如果公司已经有多套独立部署的Redis实例，且团队有充足的运维能力，可以考虑RedLock，但一定要评估好性能损耗和运维成本。
• 如果系统允许偶尔的数据重放（比如某些统计类场景），那直接用SETNX手写的简单锁都行，别为了"高级"而过度设计。

我在实际项目中见过一个反面教材：团队为了"保险"，给一个简单的发券接口上了RedLock，结果因为网络抖动导致加锁耗时飙升，接口P99从50ms涨到了800ms，用户反馈体验明显变差。后来降级成普通的RLock，配合业务上做了幂等表，问题反而全部消失。所以我的原则一直是：先保证业务正确性兜底，再追求锁的绝对可靠；分布式锁是用来减少并发冲突概率的，不是用来替代业务幂等的。

6. 避坑总结：分布式锁在项目里最容易踩的五个问题

6.1 未设置过期时间的死锁

这属于最基础但也是最高发的坑。早期版本的SETNX加锁后忘记EXPIRE，或者两步操作之间有间隙导致堆积请求全部阻塞。解决思路已经说过：用一条SET key value NX PX原子命令，或者直接用Redisson，不要自己拼两步操作。

6.2 锁误删

锁因过期自动释放后，其他线程成功加锁，原线程这时去DEL——删掉的其实是别人的锁。这个问题必须用"value校验"来防御：加锁时写入唯一标识，解锁前先GET对比，一致才DEL，而且这个"对比+删除"要用Lua脚本原子执行。Redisson内部就是这么做的，因此生产环境强烈建议直接用它而不是手写。

6.3 锁的重入问题

同一个线程在持锁状态下再次调用加锁方法，如果锁不支持重入，就会把自己阻塞死——典型的场景是加锁方法里调用了另一个也加了同一把锁的本地方法。手写SETNX方案完全不处理重入，而Redisson的RLock基于Hash结构天然支持同一线程的重入计数。如果你的业务里锁的方法有嵌套调用，务必选用支持重入的实现。

6.4 锁粒度太粗导致性能雪崩

有些同学直接用"lock:all"做全局锁，只要业务稍微复杂，所有加锁操作全部串行，系统吞吐量直接跌落一个量级。正确的做法是把锁的粒度细化：库存锁按productId、订单锁按userId或orderId、优惠券锁按couponId。锁粒度越细致，系统并发能力越强。当然，粒度太细也可能导致锁数量膨胀，需要结合业务控制——比如热点商品秒杀场景，按商品维度加锁就已经是单机热点，这时候需要考虑队列削峰或Redis原子操作来替代。

6.5 锁内做了耗时操作

锁是用来保护临界区的，但临界区越大，锁持有时间越长，其他请求等待越久，系统吞吐量越低。常见的反面案例是：在锁内部调用外部HTTP接口、做慢SQL查询、批量处理大量数据。我的建议是把锁内代码压缩到最小——只保护真正需要互斥的那几步操作，外部调用尽量放到锁外。如果实在无法避免锁内远程调用，一定要有超时控制和降级方案，比如设置tryLock的等待时间上限。

7. 拓展思考：分布式锁以外的并发控制手段

分布式锁只是并发控制工具箱里的一件工具，有些场景其实有更轻量或更合适的替代方案。

• Redis原子操作：像库存扣减这种"读-改-写"模式的场景，可以直接用DECR或Lua脚本在Redis内部完成扣减和校验，连分布式锁都不需要加。比如DECR stock:1001一条命令就完成了扣减，返回负数说明超卖。这是Redis单线程模型带来的天然原子性优势。
• 数据库乐观锁：给库存表加一个version字段，更新时校验版本号一致才执行UPDATE，CAS（Compare And Swap）的思路。这个方案适合并发冲突不频繁的场景，扣减失败就重试。上面库存案例里我特意用了乐观锁作为兜底。
• 消息队列串行化：把并发请求转化为有序消息，通过MQ的队列特性让同一商品的请求串行消费，从根源上消灭并发。秒杀场景最常见的架构就是"请求进MQ + 消费者单线程处理"，效果比分布式锁更彻底。
• 数据库分布式事务：涉及多库多表的一致性操作，可以引入Seata之类的分布式事务框架，用全局锁和事务协调保证一致性。不过引入成本高、性能开销大，非必要不建议。

这些手段不是互相排斥的，而是可以根据场景组合。比如秒杀场景：Redis原子预扣 + MQ排队 + 数据库乐观锁兜底；订单支付场景：分布式锁防并发重复支付 + 幂等表防重复通知。每种手段都有它的边界，组合使用才能构建出健壮的系统。

8. 最后的实操建议与个人经验

如果让我给第一次做分布式锁的团队一个建议，我会说：先别着急写代码，花半天时间想清楚你的锁是防什么的、失败之后会怎样，再决定用哪种方案。我们团队最初手写锁踩了不少坑，后来统一切换到Redisson，代码量大幅减少，线上问题几乎绝迹。

具体实操时，还有几个小细节非常值得注意。一是锁的命名规范，建议统一为业务前缀:锁对象:业务标识，比如lock:stock:1001，方便排查问题及监控系统过滤。二是加锁后务必打日志，记录锁的key、持有线程、等待时长、释放时间，线上出问题时这些日志能帮你快速还原现场的锁竞争情况。三是监控告警别漏掉锁等待时长，如果发现某把锁的平均等待时间持续上涨，说明临界区负载过高，要及时优化。

关于Redisson的版本，我会优先选择最新稳定版，因为分布式锁相关的Bug修复大多集中在新版本里。配置上，默认的看门狗参数（锁默认30秒、每10秒续期）适合多数场景，但如果业务里有长耗时操作，可以灵活调整lockWatchdogTimeout参数——注意这个参数是全局的，调整前要评估所有使用该RedissonClient的业务场景。

最后再提醒一个容易忽视的运维点：锁相关的key一定要设置合理的过期时间策略和监控清理机制。即使有看门狗，极端情况下（比如持有锁的进程被强制杀掉，来不及释放锁）Redis里仍可能残留少量锁key。虽然它们会因过期自动清理，但如果业务上有"加锁后长时间不释放"的异常场景，建议写个定时任务扫描锁key的存活时长，超过阈值就告警。锁key的生命周期管理这事，工程师写代码时经常忽略，但生产事故往往就藏在这些细节里。