1. 项目概述为什么我们需要Redis分布式锁在构建现代分布式系统时一个无法回避的核心挑战就是并发控制。想象一下一个电商平台的库存扣减服务部署了三个实例当“秒杀”活动开始时成千上万的请求同时涌向这三个服务节点试图扣减同一件商品的最后一件库存。如果没有一个可靠的协调机制这三个服务可能会同时读取到库存为1然后各自执行扣减操作最终导致库存被扣成负数这就是典型的“超卖”问题。解决这类问题的关键就是需要一个所有服务节点都能访问和信任的“协调者”来确保在同一时间只有一个请求能执行关键操作如扣库存、更新用户余额。这个协调者就是分布式锁。而Redis凭借其高性能、丰富的数据结构和原子操作成为了实现分布式锁的热门选择。在众多实现方案中使用SET命令配合NXNot eXists参数是最基础、最经典也是理解分布式锁原理的最佳起点。这个方案的核心思想简洁而有力利用Redis单线程执行命令的特性通过一个原子操作去“占坑”谁先占到谁就获得了锁。今天我们就来彻底拆解这个方案从原理到实现从代码到陷阱让你不仅能写出一个可用的锁更能理解其背后的每一个设计考量。2. 核心原理SET NX 如何实现锁的语义要理解SET NX分布式锁我们必须先回到锁的本质。锁无论是单机环境的synchronized还是ReentrantLock其核心语义无非是“尝试获取”、“持有”和“释放”。在分布式场景下我们需要一个所有进程都能看见的“标志位”来实现这些语义。Redis的SET key value NX命令完美地提供了“尝试获取”的原子性。2.1 命令的原子性与锁的互斥性SET key value NX命令的含义是只有当键key不存在时才进行设置操作。这个操作在Redis服务器端是原子性的。原子性意味着在Redis单线程处理命令的模型下执行SET lock:order:1234 uuid NX时不会存在多个客户端同时判断key不存在并都设置成功的情况。这就从根源上保证了“第一个设置成功的客户端获得锁”这一互斥条件。这里有一个至关重要的细节锁的键Key设计。键必须是全局唯一的且与要保护的资源强相关。例如保护订单ID为1001的订单状态更新锁的键可以设计为lock:order:1001。如果保护的是整个库存扣减服务键可以是lock:service:inventory。不恰当的键设计会导致锁粒度太粗影响并发性能或太细增加管理复杂度。2.2 锁的值Value与持有者标识很多初学者会忽略value的重要性简单地将其设为1或true。这是一个潜在的坑。value必须是一个全局唯一的值用于标识锁的持有者通常使用UUID或结合机器标识、线程ID的字符串。这样做的核心目的是在释放锁时进行安全校验。释放锁的逻辑不是简单的DEL key。考虑以下场景客户端A获取锁成功设置lock:resource uuid_a。客户端A因某些原因如Full GC阻塞导致锁超时自动释放通过PX参数设置过期时间。客户端B成功获取锁设置lock:resource uuid_b。客户端A从阻塞中恢复继续执行业务逻辑最后调用DEL lock:resource释放锁。结果客户端B持有的锁被客户端A意外释放了为了避免这种“误删”问题释放锁必须是“检查再删除”的原子操作。在Redis中我们可以使用Lua脚本来实现if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end这段脚本会先检查当前锁的值是否等于客户端传入的标识ARGV[1]只有匹配时才执行删除。由于Lua脚本在Redis中也是原子执行的这就保证了释放操作的安全性。2.3 锁的过期时间PX/EX与死锁预防分布式锁必须设置一个过期时间。这是防止死锁的生命线。如果客户端在获取锁后崩溃或者网络分区导致无法与Redis通信没有过期时间的锁将永远无法被释放其他客户端将永远等待导致系统部分或全部不可用。通过SET key value NX PX 30000我们在获取锁的同时为其设置一个30秒的过期时间。这意味着无论客户端是否正常释放这把锁最多持有30秒后就会由Redis自动删除。注意过期时间的设置是一门艺术。设置太短业务逻辑可能还没执行完锁就失效了导致锁保护失效出现并发问题。设置太长一旦客户端故障其他客户端需要等待更长时间才能获取锁影响系统可用性。这个值需要根据实际业务逻辑的平均耗时和最大耗时P99或P999来评估通常设置为平均耗时的3-5倍并留有充分余量。3. 完整实现与代码拆解理解了核心原理后我们来看一个完整的、生产可用的Java实现示例。我们将使用Spring Boot和Lettuce或Jedis客户端并重点讲解每一个环节的考量。3.1 基础工具类封装首先我们封装一个分布式锁的工具类。这个类将提供获取锁、释放锁等核心方法。import org.springframework.data.redis.core.RedisTemplate; import org.springframework.data.redis.core.script.DefaultRedisScript; import org.springframework.stereotype.Component; import java.util.Collections; import java.util.UUID; import java.util.concurrent.TimeUnit; Component public class RedisDistributedLock { private final RedisTemplateString, String redisTemplate; private final ThreadLocalString lockValueHolder new ThreadLocal(); // 释放锁的Lua脚本 private static final String RELEASE_LOCK_SCRIPT if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; private final DefaultRedisScriptLong releaseScript; public RedisDistributedLock(RedisTemplateString, String redisTemplate) { this.redisTemplate redisTemplate; this.releaseScript new DefaultRedisScript(); this.releaseScript.setScriptText(RELEASE_LOCK_SCRIPT); this.releaseScript.setResultType(Long.class); } /** * 尝试获取分布式锁 * param lockKey 锁的键 * param expireTime 锁的过期时间 * param timeUnit 过期时间单位 * param waitTime 获取锁的最大等待时间 * param retryInterval 重试间隔 * return 是否获取成功 */ public boolean tryLock(String lockKey, long expireTime, TimeUnit timeUnit, long waitTime, long retryInterval) throws InterruptedException { String value UUID.randomUUID().toString(); long waitMillis TimeUnit.MILLISECONDS.convert(waitTime, timeUnit); long retryMillis TimeUnit.MILLISECONDS.convert(retryInterval, timeUnit); long deadline System.currentTimeMillis() waitMillis; while (System.currentTimeMillis() deadline) { // 核心原子性尝试获取锁 Boolean success redisTemplate.opsForValue() .setIfAbsent(lockKey, value, expireTime, timeUnit); if (Boolean.TRUE.equals(success)) { // 获取成功将value保存到ThreadLocal供释放时使用 lockValueHolder.set(value); return true; } // 获取失败休眠一段时间后重试 Thread.sleep(retryMillis); } // 等待超时获取失败 return false; } /** * 释放分布式锁 * param lockKey 锁的键 * return 是否释放成功 */ public boolean unlock(String lockKey) { String value lockValueHolder.get(); if (value null) { // 当前线程并未持有锁可能是重复释放或逻辑错误 throw new IllegalStateException(Current thread does not hold the lock: lockKey); } // 使用Lua脚本原子性释放锁 Long result redisTemplate.execute( releaseScript, Collections.singletonList(lockKey), value ); lockValueHolder.remove(); // 清理ThreadLocal return result ! null result 1L; } }3.2 关键代码解析与设计考量锁值生成与存储使用UUID.randomUUID().toString()生成全局唯一的锁值。将其存储在ThreadLocal中确保了在同一个线程内获取和释放锁时使用的是同一个值且避免了在方法参数中传递的麻烦和出错可能。获取锁的逻辑tryLock方法提供了等待机制。它不会在第一次尝试失败后立即返回而是会在指定的waitTime内以retryInterval为间隔不断重试。这种“自旋”式的重试策略在锁竞争不极端的情况下比立即失败返回给上游处理更友好。但retryInterval不宜过短否则会给Redis带来不必要的压力。释放锁的安全保障unlock方法的核心是执行那段预加载的Lua脚本。它传入了锁的键和当前线程持有的值。只有键对应的值匹配时才会执行删除。execute方法返回的是Lua脚本的执行结果删除成功返回1否则返回0。我们通过判断结果是否为1来确定是否释放成功。异常处理与状态清理在unlock方法中如果ThreadLocal中没有值说明当前线程并不持有锁可能是重复调用unlock或者tryLock根本没被调用。这里我们选择抛出异常强制开发者检查调用逻辑这比静默失败更安全。最后无论释放成功与否都必须调用lockValueHolder.remove()清理ThreadLocal防止内存泄漏。3.3 业务层使用示例下面我们模拟一个扣减库存的业务场景。Service public class InventoryService { Autowired private RedisDistributedLock distributedLock; Autowired private InventoryMapper inventoryMapper; // 假设的数据库Mapper private static final String LOCK_KEY_PREFIX lock:inventory:; public boolean deductStock(Long productId, Integer quantity) { String lockKey LOCK_KEY_PREFIX productId; boolean lockAcquired false; try { // 尝试获取锁最多等待2秒每次重试间隔100毫秒锁持有时间10秒 lockAcquired distributedLock.tryLock(lockKey, 10, TimeUnit.SECONDS, 2, 100); if (!lockAcquired) { // 获取锁失败可以记录日志、抛出特定异常或返回错误码给前端 throw new RuntimeException(系统繁忙请稍后重试); } // ---------- 临界区代码开始 ---------- // 1. 查询当前库存 Inventory inventory inventoryMapper.selectById(productId); if (inventory null || inventory.getStock() quantity) { throw new RuntimeException(库存不足); } // 2. 执行扣减 inventory.setStock(inventory.getStock() - quantity); inventoryMapper.updateById(inventory); // 模拟一个可能耗时的操作 Thread.sleep(2000); // ---------- 临界区代码结束 ---------- return true; } catch (InterruptedException e) { Thread.currentThread().interrupt(); throw new RuntimeException(操作被中断, e); } catch (Exception e) { // 处理业务异常 throw e; } finally { // 务必在finally块中释放锁 if (lockAcquired) { try { distributedLock.unlock(lockKey); } catch (Exception e) { // 释放锁失败必须记录严重日志并考虑告警 log.error(释放分布式锁失败lockKey: {}, lockKey, e); // 此处可以根据策略决定是否重试释放但需谨慎避免死循环 } } } } }4. 深入陷阱SET NX方案的经典问题与应对一个看似简单的SET NX方案在实际生产环境中布满了陷阱。只有深刻理解这些问题才能说真正掌握了分布式锁。4.1 锁过期而业务未执行完锁提前释放这是SET NX PX方案最经典的问题。客户端A获取锁设置了30秒过期。但由于Full GC、网络延迟或业务逻辑本身复杂操作持续了35秒。在第30秒时Redis自动删除了锁。此时客户端B成功获取锁并开始操作共享资源。片刻后客户端A终于执行完毕调用释放锁逻辑由于Lua脚本校验值可能释放失败但也可能在其执行Lua脚本前的一瞬间锁刚好被B持有且值匹配不这概率极低但理论存在更复杂时序问题。更糟糕的是A在锁失效后仍然认为自己持有锁继续执行了非线程安全的代码。应对策略设置合理的过期时间这需要压测和监控。统计业务逻辑的P99、P999耗时将过期时间设置为P999耗时的2-3倍以上。锁续期Watch Dog启动一个守护线程在持有锁期间定期例如每隔过期时间的1/3去检查锁是否还存在且值是否匹配如果匹配则重置其过期时间。这要求锁的客户端是“活”的。Redisson客户端库内置了这个机制。业务设计兼容让业务逻辑具备一定的幂等性或者通过状态机、版本号如乐观锁等方式使得即使锁偶尔失效也不会造成不可逆的脏数据。这是一种更根本的、结合业务的设计思路。4.2 主从切换/脑裂导致锁失效在Redis主从架构中客户端向主节点写入锁。如果主节点在将锁信息同步到从节点之前宕机而哨兵或集群协议迅速选举出一个从节点作为新的主节点那么这个新的主节点上并没有之前客户端持有的锁信息。此时另一个客户端可以向新主节点申请锁并成功导致同一个锁被两个客户端同时持有。应对策略SET NX方案本身无法完全解决此问题因为它依赖于单Redis节点的数据强一致性。要应对此问题需要更复杂的机制RedLock算法Redis作者提出的一种分布式锁算法需要同时向多个独立的Redis主节点申请锁当从大多数N/21节点上获取成功时才算真正持有锁。这牺牲了部分性能来换取更高的可靠性。但RedLock本身也存在争议需要谨慎评估。使用强一致性的存储系统如ZooKeeper、etcd。这些系统通过ZAB或Raft协议保证了数据的强一致性从根源上避免了主从数据不一致问题但通常性能低于Redis。业务降级评估锁失效的真实影响。如果锁失效仅导致少量重复处理如发送了重复的消息可以通过下游的幂等消费来容忍这可能比引入复杂锁方案的成本更低。4.3 客户端长时间阻塞导致的连锁反应客户端在持有锁期间发生长时间STWStop-The-World如Full GC其守护线程也无法进行锁续期。这会导致锁过期释放其他客户端获得锁。当阻塞的客户端恢复后它感知不到锁已丢失会继续操作资源并与新锁持有者产生冲突。同时它还会尝试释放锁可能失败。应对策略JVM优化这是根本减少长时间GC的发生。监控GC日志优化堆大小、选择低延迟垃圾收集器如G1、ZGC。设置合理的锁超时超时时间应远大于可能的最长STW时间。添加锁持有状态校验在业务逻辑的关键步骤中可以再次检查锁是否仍由自己持有通过GET命令对比value。但这会增加复杂度和开销。5. 生产环境最佳实践与配置要点将SET NX分布式锁用于生产不能只停留在跑通Demo。以下是一些关键实践。5.1 Redis连接与客户端选型连接池务必使用连接池如Lettuce内置或Jedis Pool。频繁创建销毁TCP连接是性能杀手。需要根据业务QPS合理配置最大连接数、最小空闲连接数等参数。客户端选型Lettuce基于Netty异步非阻塞性能高资源消耗相对少支持响应式编程。在Spring Boot 2.x后是默认客户端。Jedis老牌客户端直连模式简单但每个连接非线程安全通常需配合连接池使用。在极高并发下Lettuce通常表现更优。序列化确保RedisTemplate的Key和Value序列化器配置正确。通常Key使用StringRedisSerializerValue可根据情况使用Jackson2JsonRedisSerializer或StringRedisSerializer。在我们的锁场景中Key和Value都是字符串。5.2 锁的监控与治理监控关键指标锁获取成功率成功率下降可能意味着竞争激烈或Redis异常。锁平均持有时间与设置的过期时间对比如果平均持有时间接近过期时间说明业务逻辑可能太慢或过期时间设置太紧。锁等待时间tryLock方法中实际等待的时长用于评估锁竞争程度。Redis命令延迟监控SET、GET、EVAL执行Lua脚本等命令的P99延迟延迟飙升会影响锁的性能和可靠性。日志记录在获取锁成功/失败、释放锁时记录详细的日志包括锁Key、耗时、客户端标识等。这对于排查问题至关重要。设置锁Key前缀如lock:方便在Redis可视化工具中搜索和管理也便于通过keys lock:*生产环境慎用或SCAN命令进行模式匹配清理僵尸锁虽然有过期时间但监控总有帮助。5.3 封装与使用规范模板方法封装可以进一步封装提供一种更易用的“执行体”模式。public T T executeWithLock(String lockKey, long expireTime, TimeUnit timeUnit, SupplierT supplier) { // 获取锁... try { return supplier.get(); // 执行传入的业务逻辑 } finally { // 释放锁... } } // 使用 executeWithLock(“lock:order”, 10, TimeUnit.SECONDS, () - { // 业务逻辑 return result; });强制解锁工具在极端情况下如持有锁的客户端进程崩溃且无法恢复可能需要一个管理员工具来强制删除某个锁Key。这个工具必须慎用且最好有二次确认和审计日志。定义清晰的锁粒度在项目初期就约定锁Key的命名规范避免不同团队、不同业务之间产生冲突或混淆。6. 常见问题排查与调试技巧在实际开发运维中你会遇到各种奇怪的问题。这里记录一些典型的排查思路。6.1 问题速查表问题现象可能原因排查步骤与解决方案获取锁永远失败超时返回。1. 锁被某个客户端长期占用未释放死锁。2. Redis服务不可用或网络不通。3. 锁过期时间设置过长且获取锁的客户端崩溃。1. 连接Redis用TTL key查看锁剩余生存时间。如果一直有值且不减少可能是客户端未正确释放。检查持有该锁的客户端应用日志。2. 检查Redis监控、网络连通性。3. 如果确认客户端已崩溃使用DEL key生产环境慎用需确认或通过管理工具强制释放。业务中出现数据不一致疑似锁失效。1. 业务逻辑执行时间超过锁过期时间锁提前释放。2. Redis主从切换导致锁丢失。3. 客户端长时间GC守护线程未能续期。1. 在获取锁和释放锁时打印耗时日志对比过期时间。2. 检查Redis哨兵/集群日志确认是否有主从切换事件。3. 分析客户端应用的GC日志观察是否有Full GC。释放锁时抛出“Current thread does not hold the lock”异常。1.tryLock方法未成功却在finally块中调用了unlock。2. 同一个线程内重复调用unlock。3.ThreadLocal值被意外清除如使用了线程池线程被复用。1. 检查tryLock返回值判断逻辑确保只有获取成功才在finally中释放。2. 检查业务逻辑避免重复释放。3. 确保在unlock方法中remove了ThreadLocal并且业务逻辑没有在其他地方操作它。Redis CPU或内存使用率异常高。1. 锁竞争激烈大量客户端频繁执行SET命令重试。2.retryInterval设置过小导致重试QPS过高。3. 锁Key没有设置过期时间导致内存泄漏最严重。1. 监控锁获取成功率优化业务逻辑或拆分锁粒度以减少竞争。2. 适当增大重试间隔如从10ms调整为50ms或100ms。3.紧急检查所有锁Key的TTL确保都设置了过期时间。6.2 调试技巧实录模拟锁竞争写一个简单的测试程序启动多个线程同时调用tryLock观察日志输出和Redis中Key的变化直观理解锁的互斥性。使用Redis CLI观察在测试环境打开Redis CLI使用monitor命令可以实时看到所有命令观察锁的获取、释放过程是否符合预期。日志染色在锁的工具类中为每个锁请求生成一个唯一的追踪IDTraceID并贯穿于获取、持有、释放的全过程日志中。这样在排查问题时可以通过一个TraceID串联起所有相关日志。压测与混沌工程对使用了分布式锁的核心接口进行压测观察在高并发下锁的表现。可以配合混沌实验工具模拟网络延迟、Redis节点宕机等场景验证系统的健壮性。7. 方案演进何时该考虑更复杂的锁方案SET NX方案简单有效足以应对大多数中低并发、对可靠性要求不是极端苛刻的场景。但是当你的系统面临以下情况时就需要考虑升级方案了对可靠性要求极高金融核心交易等场景无法接受因主从切换导致的极低概率锁失效。锁竞争成为性能瓶颈大量线程阻塞在获取锁的阶段即使优化业务和粒度也无济于事。需要可重入锁同一个线程可以多次获取同一把锁。SET NX方案需要自己维护重入计数比较麻烦。需要公平锁按照请求锁的顺序来获取锁防止某些线程饿死。此时你可以考虑使用成熟的客户端库如Redisson。它基于Redis实现了可重入锁、公平锁、联锁、红锁等多种分布式锁并内置了Watch Dog锁续期机制生产级特性完善是很多项目的首选。换用CP系统如果业务对一致性的要求绝对高于可用性可以考虑使用ZooKeeper或etcd来实现分布式锁。它们基于临时顺序节点和Watch机制能提供严格的强一致性保证。数据库分布式锁利用数据库的唯一约束或乐观锁版本号也是一种简单方案但数据库压力大性能一般通常作为备选。我个人在实际项目中对于大部分业务场景如果Redis本身是高可用的如哨兵模式或集群模式并且业务对锁的短暂失效有一定的容忍度可通过幂等、状态校验等手段弥补那么精心设计和监控下的SET NX PX方案完全够用。它的优势在于理解和维护成本低性能高。在引入更复杂的方案如RedLock前一定要评估其带来的复杂度和真实收益避免过度设计。 Redis分布式锁核心原理与生产实践：从SET NX到高并发场景应用
1. 项目概述为什么我们需要Redis分布式锁在构建现代分布式系统时一个无法回避的核心挑战就是并发控制。想象一下一个电商平台的库存扣减服务部署了三个实例当“秒杀”活动开始时成千上万的请求同时涌向这三个服务节点试图扣减同一件商品的最后一件库存。如果没有一个可靠的协调机制这三个服务可能会同时读取到库存为1然后各自执行扣减操作最终导致库存被扣成负数这就是典型的“超卖”问题。解决这类问题的关键就是需要一个所有服务节点都能访问和信任的“协调者”来确保在同一时间只有一个请求能执行关键操作如扣库存、更新用户余额。这个协调者就是分布式锁。而Redis凭借其高性能、丰富的数据结构和原子操作成为了实现分布式锁的热门选择。在众多实现方案中使用SET命令配合NXNot eXists参数是最基础、最经典也是理解分布式锁原理的最佳起点。这个方案的核心思想简洁而有力利用Redis单线程执行命令的特性通过一个原子操作去“占坑”谁先占到谁就获得了锁。今天我们就来彻底拆解这个方案从原理到实现从代码到陷阱让你不仅能写出一个可用的锁更能理解其背后的每一个设计考量。2. 核心原理SET NX 如何实现锁的语义要理解SET NX分布式锁我们必须先回到锁的本质。锁无论是单机环境的synchronized还是ReentrantLock其核心语义无非是“尝试获取”、“持有”和“释放”。在分布式场景下我们需要一个所有进程都能看见的“标志位”来实现这些语义。Redis的SET key value NX命令完美地提供了“尝试获取”的原子性。2.1 命令的原子性与锁的互斥性SET key value NX命令的含义是只有当键key不存在时才进行设置操作。这个操作在Redis服务器端是原子性的。原子性意味着在Redis单线程处理命令的模型下执行SET lock:order:1234 uuid NX时不会存在多个客户端同时判断key不存在并都设置成功的情况。这就从根源上保证了“第一个设置成功的客户端获得锁”这一互斥条件。这里有一个至关重要的细节锁的键Key设计。键必须是全局唯一的且与要保护的资源强相关。例如保护订单ID为1001的订单状态更新锁的键可以设计为lock:order:1001。如果保护的是整个库存扣减服务键可以是lock:service:inventory。不恰当的键设计会导致锁粒度太粗影响并发性能或太细增加管理复杂度。2.2 锁的值Value与持有者标识很多初学者会忽略value的重要性简单地将其设为1或true。这是一个潜在的坑。value必须是一个全局唯一的值用于标识锁的持有者通常使用UUID或结合机器标识、线程ID的字符串。这样做的核心目的是在释放锁时进行安全校验。释放锁的逻辑不是简单的DEL key。考虑以下场景客户端A获取锁成功设置lock:resource uuid_a。客户端A因某些原因如Full GC阻塞导致锁超时自动释放通过PX参数设置过期时间。客户端B成功获取锁设置lock:resource uuid_b。客户端A从阻塞中恢复继续执行业务逻辑最后调用DEL lock:resource释放锁。结果客户端B持有的锁被客户端A意外释放了为了避免这种“误删”问题释放锁必须是“检查再删除”的原子操作。在Redis中我们可以使用Lua脚本来实现if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end这段脚本会先检查当前锁的值是否等于客户端传入的标识ARGV[1]只有匹配时才执行删除。由于Lua脚本在Redis中也是原子执行的这就保证了释放操作的安全性。2.3 锁的过期时间PX/EX与死锁预防分布式锁必须设置一个过期时间。这是防止死锁的生命线。如果客户端在获取锁后崩溃或者网络分区导致无法与Redis通信没有过期时间的锁将永远无法被释放其他客户端将永远等待导致系统部分或全部不可用。通过SET key value NX PX 30000我们在获取锁的同时为其设置一个30秒的过期时间。这意味着无论客户端是否正常释放这把锁最多持有30秒后就会由Redis自动删除。注意过期时间的设置是一门艺术。设置太短业务逻辑可能还没执行完锁就失效了导致锁保护失效出现并发问题。设置太长一旦客户端故障其他客户端需要等待更长时间才能获取锁影响系统可用性。这个值需要根据实际业务逻辑的平均耗时和最大耗时P99或P999来评估通常设置为平均耗时的3-5倍并留有充分余量。3. 完整实现与代码拆解理解了核心原理后我们来看一个完整的、生产可用的Java实现示例。我们将使用Spring Boot和Lettuce或Jedis客户端并重点讲解每一个环节的考量。3.1 基础工具类封装首先我们封装一个分布式锁的工具类。这个类将提供获取锁、释放锁等核心方法。import org.springframework.data.redis.core.RedisTemplate; import org.springframework.data.redis.core.script.DefaultRedisScript; import org.springframework.stereotype.Component; import java.util.Collections; import java.util.UUID; import java.util.concurrent.TimeUnit; Component public class RedisDistributedLock { private final RedisTemplateString, String redisTemplate; private final ThreadLocalString lockValueHolder new ThreadLocal(); // 释放锁的Lua脚本 private static final String RELEASE_LOCK_SCRIPT if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; private final DefaultRedisScriptLong releaseScript; public RedisDistributedLock(RedisTemplateString, String redisTemplate) { this.redisTemplate redisTemplate; this.releaseScript new DefaultRedisScript(); this.releaseScript.setScriptText(RELEASE_LOCK_SCRIPT); this.releaseScript.setResultType(Long.class); } /** * 尝试获取分布式锁 * param lockKey 锁的键 * param expireTime 锁的过期时间 * param timeUnit 过期时间单位 * param waitTime 获取锁的最大等待时间 * param retryInterval 重试间隔 * return 是否获取成功 */ public boolean tryLock(String lockKey, long expireTime, TimeUnit timeUnit, long waitTime, long retryInterval) throws InterruptedException { String value UUID.randomUUID().toString(); long waitMillis TimeUnit.MILLISECONDS.convert(waitTime, timeUnit); long retryMillis TimeUnit.MILLISECONDS.convert(retryInterval, timeUnit); long deadline System.currentTimeMillis() waitMillis; while (System.currentTimeMillis() deadline) { // 核心原子性尝试获取锁 Boolean success redisTemplate.opsForValue() .setIfAbsent(lockKey, value, expireTime, timeUnit); if (Boolean.TRUE.equals(success)) { // 获取成功将value保存到ThreadLocal供释放时使用 lockValueHolder.set(value); return true; } // 获取失败休眠一段时间后重试 Thread.sleep(retryMillis); } // 等待超时获取失败 return false; } /** * 释放分布式锁 * param lockKey 锁的键 * return 是否释放成功 */ public boolean unlock(String lockKey) { String value lockValueHolder.get(); if (value null) { // 当前线程并未持有锁可能是重复释放或逻辑错误 throw new IllegalStateException(Current thread does not hold the lock: lockKey); } // 使用Lua脚本原子性释放锁 Long result redisTemplate.execute( releaseScript, Collections.singletonList(lockKey), value ); lockValueHolder.remove(); // 清理ThreadLocal return result ! null result 1L; } }3.2 关键代码解析与设计考量锁值生成与存储使用UUID.randomUUID().toString()生成全局唯一的锁值。将其存储在ThreadLocal中确保了在同一个线程内获取和释放锁时使用的是同一个值且避免了在方法参数中传递的麻烦和出错可能。获取锁的逻辑tryLock方法提供了等待机制。它不会在第一次尝试失败后立即返回而是会在指定的waitTime内以retryInterval为间隔不断重试。这种“自旋”式的重试策略在锁竞争不极端的情况下比立即失败返回给上游处理更友好。但retryInterval不宜过短否则会给Redis带来不必要的压力。释放锁的安全保障unlock方法的核心是执行那段预加载的Lua脚本。它传入了锁的键和当前线程持有的值。只有键对应的值匹配时才会执行删除。execute方法返回的是Lua脚本的执行结果删除成功返回1否则返回0。我们通过判断结果是否为1来确定是否释放成功。异常处理与状态清理在unlock方法中如果ThreadLocal中没有值说明当前线程并不持有锁可能是重复调用unlock或者tryLock根本没被调用。这里我们选择抛出异常强制开发者检查调用逻辑这比静默失败更安全。最后无论释放成功与否都必须调用lockValueHolder.remove()清理ThreadLocal防止内存泄漏。3.3 业务层使用示例下面我们模拟一个扣减库存的业务场景。Service public class InventoryService { Autowired private RedisDistributedLock distributedLock; Autowired private InventoryMapper inventoryMapper; // 假设的数据库Mapper private static final String LOCK_KEY_PREFIX lock:inventory:; public boolean deductStock(Long productId, Integer quantity) { String lockKey LOCK_KEY_PREFIX productId; boolean lockAcquired false; try { // 尝试获取锁最多等待2秒每次重试间隔100毫秒锁持有时间10秒 lockAcquired distributedLock.tryLock(lockKey, 10, TimeUnit.SECONDS, 2, 100); if (!lockAcquired) { // 获取锁失败可以记录日志、抛出特定异常或返回错误码给前端 throw new RuntimeException(系统繁忙请稍后重试); } // ---------- 临界区代码开始 ---------- // 1. 查询当前库存 Inventory inventory inventoryMapper.selectById(productId); if (inventory null || inventory.getStock() quantity) { throw new RuntimeException(库存不足); } // 2. 执行扣减 inventory.setStock(inventory.getStock() - quantity); inventoryMapper.updateById(inventory); // 模拟一个可能耗时的操作 Thread.sleep(2000); // ---------- 临界区代码结束 ---------- return true; } catch (InterruptedException e) { Thread.currentThread().interrupt(); throw new RuntimeException(操作被中断, e); } catch (Exception e) { // 处理业务异常 throw e; } finally { // 务必在finally块中释放锁 if (lockAcquired) { try { distributedLock.unlock(lockKey); } catch (Exception e) { // 释放锁失败必须记录严重日志并考虑告警 log.error(释放分布式锁失败lockKey: {}, lockKey, e); // 此处可以根据策略决定是否重试释放但需谨慎避免死循环 } } } } }4. 深入陷阱SET NX方案的经典问题与应对一个看似简单的SET NX方案在实际生产环境中布满了陷阱。只有深刻理解这些问题才能说真正掌握了分布式锁。4.1 锁过期而业务未执行完锁提前释放这是SET NX PX方案最经典的问题。客户端A获取锁设置了30秒过期。但由于Full GC、网络延迟或业务逻辑本身复杂操作持续了35秒。在第30秒时Redis自动删除了锁。此时客户端B成功获取锁并开始操作共享资源。片刻后客户端A终于执行完毕调用释放锁逻辑由于Lua脚本校验值可能释放失败但也可能在其执行Lua脚本前的一瞬间锁刚好被B持有且值匹配不这概率极低但理论存在更复杂时序问题。更糟糕的是A在锁失效后仍然认为自己持有锁继续执行了非线程安全的代码。应对策略设置合理的过期时间这需要压测和监控。统计业务逻辑的P99、P999耗时将过期时间设置为P999耗时的2-3倍以上。锁续期Watch Dog启动一个守护线程在持有锁期间定期例如每隔过期时间的1/3去检查锁是否还存在且值是否匹配如果匹配则重置其过期时间。这要求锁的客户端是“活”的。Redisson客户端库内置了这个机制。业务设计兼容让业务逻辑具备一定的幂等性或者通过状态机、版本号如乐观锁等方式使得即使锁偶尔失效也不会造成不可逆的脏数据。这是一种更根本的、结合业务的设计思路。4.2 主从切换/脑裂导致锁失效在Redis主从架构中客户端向主节点写入锁。如果主节点在将锁信息同步到从节点之前宕机而哨兵或集群协议迅速选举出一个从节点作为新的主节点那么这个新的主节点上并没有之前客户端持有的锁信息。此时另一个客户端可以向新主节点申请锁并成功导致同一个锁被两个客户端同时持有。应对策略SET NX方案本身无法完全解决此问题因为它依赖于单Redis节点的数据强一致性。要应对此问题需要更复杂的机制RedLock算法Redis作者提出的一种分布式锁算法需要同时向多个独立的Redis主节点申请锁当从大多数N/21节点上获取成功时才算真正持有锁。这牺牲了部分性能来换取更高的可靠性。但RedLock本身也存在争议需要谨慎评估。使用强一致性的存储系统如ZooKeeper、etcd。这些系统通过ZAB或Raft协议保证了数据的强一致性从根源上避免了主从数据不一致问题但通常性能低于Redis。业务降级评估锁失效的真实影响。如果锁失效仅导致少量重复处理如发送了重复的消息可以通过下游的幂等消费来容忍这可能比引入复杂锁方案的成本更低。4.3 客户端长时间阻塞导致的连锁反应客户端在持有锁期间发生长时间STWStop-The-World如Full GC其守护线程也无法进行锁续期。这会导致锁过期释放其他客户端获得锁。当阻塞的客户端恢复后它感知不到锁已丢失会继续操作资源并与新锁持有者产生冲突。同时它还会尝试释放锁可能失败。应对策略JVM优化这是根本减少长时间GC的发生。监控GC日志优化堆大小、选择低延迟垃圾收集器如G1、ZGC。设置合理的锁超时超时时间应远大于可能的最长STW时间。添加锁持有状态校验在业务逻辑的关键步骤中可以再次检查锁是否仍由自己持有通过GET命令对比value。但这会增加复杂度和开销。5. 生产环境最佳实践与配置要点将SET NX分布式锁用于生产不能只停留在跑通Demo。以下是一些关键实践。5.1 Redis连接与客户端选型连接池务必使用连接池如Lettuce内置或Jedis Pool。频繁创建销毁TCP连接是性能杀手。需要根据业务QPS合理配置最大连接数、最小空闲连接数等参数。客户端选型Lettuce基于Netty异步非阻塞性能高资源消耗相对少支持响应式编程。在Spring Boot 2.x后是默认客户端。Jedis老牌客户端直连模式简单但每个连接非线程安全通常需配合连接池使用。在极高并发下Lettuce通常表现更优。序列化确保RedisTemplate的Key和Value序列化器配置正确。通常Key使用StringRedisSerializerValue可根据情况使用Jackson2JsonRedisSerializer或StringRedisSerializer。在我们的锁场景中Key和Value都是字符串。5.2 锁的监控与治理监控关键指标锁获取成功率成功率下降可能意味着竞争激烈或Redis异常。锁平均持有时间与设置的过期时间对比如果平均持有时间接近过期时间说明业务逻辑可能太慢或过期时间设置太紧。锁等待时间tryLock方法中实际等待的时长用于评估锁竞争程度。Redis命令延迟监控SET、GET、EVAL执行Lua脚本等命令的P99延迟延迟飙升会影响锁的性能和可靠性。日志记录在获取锁成功/失败、释放锁时记录详细的日志包括锁Key、耗时、客户端标识等。这对于排查问题至关重要。设置锁Key前缀如lock:方便在Redis可视化工具中搜索和管理也便于通过keys lock:*生产环境慎用或SCAN命令进行模式匹配清理僵尸锁虽然有过期时间但监控总有帮助。5.3 封装与使用规范模板方法封装可以进一步封装提供一种更易用的“执行体”模式。public T T executeWithLock(String lockKey, long expireTime, TimeUnit timeUnit, SupplierT supplier) { // 获取锁... try { return supplier.get(); // 执行传入的业务逻辑 } finally { // 释放锁... } } // 使用 executeWithLock(“lock:order”, 10, TimeUnit.SECONDS, () - { // 业务逻辑 return result; });强制解锁工具在极端情况下如持有锁的客户端进程崩溃且无法恢复可能需要一个管理员工具来强制删除某个锁Key。这个工具必须慎用且最好有二次确认和审计日志。定义清晰的锁粒度在项目初期就约定锁Key的命名规范避免不同团队、不同业务之间产生冲突或混淆。6. 常见问题排查与调试技巧在实际开发运维中你会遇到各种奇怪的问题。这里记录一些典型的排查思路。6.1 问题速查表问题现象可能原因排查步骤与解决方案获取锁永远失败超时返回。1. 锁被某个客户端长期占用未释放死锁。2. Redis服务不可用或网络不通。3. 锁过期时间设置过长且获取锁的客户端崩溃。1. 连接Redis用TTL key查看锁剩余生存时间。如果一直有值且不减少可能是客户端未正确释放。检查持有该锁的客户端应用日志。2. 检查Redis监控、网络连通性。3. 如果确认客户端已崩溃使用DEL key生产环境慎用需确认或通过管理工具强制释放。业务中出现数据不一致疑似锁失效。1. 业务逻辑执行时间超过锁过期时间锁提前释放。2. Redis主从切换导致锁丢失。3. 客户端长时间GC守护线程未能续期。1. 在获取锁和释放锁时打印耗时日志对比过期时间。2. 检查Redis哨兵/集群日志确认是否有主从切换事件。3. 分析客户端应用的GC日志观察是否有Full GC。释放锁时抛出“Current thread does not hold the lock”异常。1.tryLock方法未成功却在finally块中调用了unlock。2. 同一个线程内重复调用unlock。3.ThreadLocal值被意外清除如使用了线程池线程被复用。1. 检查tryLock返回值判断逻辑确保只有获取成功才在finally中释放。2. 检查业务逻辑避免重复释放。3. 确保在unlock方法中remove了ThreadLocal并且业务逻辑没有在其他地方操作它。Redis CPU或内存使用率异常高。1. 锁竞争激烈大量客户端频繁执行SET命令重试。2.retryInterval设置过小导致重试QPS过高。3. 锁Key没有设置过期时间导致内存泄漏最严重。1. 监控锁获取成功率优化业务逻辑或拆分锁粒度以减少竞争。2. 适当增大重试间隔如从10ms调整为50ms或100ms。3.紧急检查所有锁Key的TTL确保都设置了过期时间。6.2 调试技巧实录模拟锁竞争写一个简单的测试程序启动多个线程同时调用tryLock观察日志输出和Redis中Key的变化直观理解锁的互斥性。使用Redis CLI观察在测试环境打开Redis CLI使用monitor命令可以实时看到所有命令观察锁的获取、释放过程是否符合预期。日志染色在锁的工具类中为每个锁请求生成一个唯一的追踪IDTraceID并贯穿于获取、持有、释放的全过程日志中。这样在排查问题时可以通过一个TraceID串联起所有相关日志。压测与混沌工程对使用了分布式锁的核心接口进行压测观察在高并发下锁的表现。可以配合混沌实验工具模拟网络延迟、Redis节点宕机等场景验证系统的健壮性。7. 方案演进何时该考虑更复杂的锁方案SET NX方案简单有效足以应对大多数中低并发、对可靠性要求不是极端苛刻的场景。但是当你的系统面临以下情况时就需要考虑升级方案了对可靠性要求极高金融核心交易等场景无法接受因主从切换导致的极低概率锁失效。锁竞争成为性能瓶颈大量线程阻塞在获取锁的阶段即使优化业务和粒度也无济于事。需要可重入锁同一个线程可以多次获取同一把锁。SET NX方案需要自己维护重入计数比较麻烦。需要公平锁按照请求锁的顺序来获取锁防止某些线程饿死。此时你可以考虑使用成熟的客户端库如Redisson。它基于Redis实现了可重入锁、公平锁、联锁、红锁等多种分布式锁并内置了Watch Dog锁续期机制生产级特性完善是很多项目的首选。换用CP系统如果业务对一致性的要求绝对高于可用性可以考虑使用ZooKeeper或etcd来实现分布式锁。它们基于临时顺序节点和Watch机制能提供严格的强一致性保证。数据库分布式锁利用数据库的唯一约束或乐观锁版本号也是一种简单方案但数据库压力大性能一般通常作为备选。我个人在实际项目中对于大部分业务场景如果Redis本身是高可用的如哨兵模式或集群模式并且业务对锁的短暂失效有一定的容忍度可通过幂等、状态校验等手段弥补那么精心设计和监控下的SET NX PX方案完全够用。它的优势在于理解和维护成本低性能高。在引入更复杂的方案如RedLock前一定要评估其带来的复杂度和真实收益避免过度设计。