1. 从单机锁到分布式锁为什么我们需要Redis Set NX在单机应用的时代处理并发资源竞争我们通常会想到Java里的synchronized关键字或者ReentrantLock。这些锁机制在单个JVM进程内运行得非常好因为它们依赖于进程内的内存状态来协调线程。但是当你的应用从一台服务器扩展到两台、十台甚至上百台服务器时情况就完全变了。想象一下一个商品秒杀活动库存扣减的逻辑部署在十台服务器上如果还用synchronized那它只能锁住自己这台服务器上的线程其他九台服务器的请求依然会一拥而上导致库存超卖。这就是典型的分布式环境下的并发问题。分布式锁就是为了解决这个问题而生的。它的核心目标是在分布式系统这个“无共享内存”的多个进程或主机之间提供一种互斥机制确保在同一时间只有一个客户端能对某个共享资源进行操作。实现分布式锁的方案有很多比如基于数据库的唯一索引、基于ZooKeeper的临时有序节点而基于Redis的实现因其高性能和相对简单的模型成为了最流行的选择之一。在Redis的众多命令中SET命令配合NX和PX参数是实现分布式锁最基础、最经典的方式。SET key value NX PX 30000这一行简单的命令几乎成了面试中关于分布式锁的“开场白”。它看起来简单但背后涉及了原子性、锁超时、死锁预防等一系列关键问题。很多人觉得会用这行命令就等于懂了分布式锁但实际生产环境中仅仅知道这行命令是远远不够的从锁的获取、持有到释放每一个环节都藏着“坑”。这篇文章我就结合自己这些年趟过的雷从头到尾拆解一下用RedisSET NX实现分布式锁的完整逻辑、那些容易忽略的细节以及如何让它变得更健壮。2. SET NX PX一行命令背后的精妙设计我们先来彻底理解这行核心命令SET lock:order:1234 client_unique_id NX PX 30000。我们把它拆开看每一个部分都不是多余的。lock:order:1234 锁的Key。这是锁的唯一标识必须与你要保护的资源强关联。比如保护订单ID为1234的订单Key就应该是lock:order:1234。这里有个最佳实践使用业务前缀如lock:这样在Redis可视化工具里一目了然也便于后续的监控和管理。Key的设计要保证全局唯一性避免不同业务间的锁意外冲突。client_unique_id 锁的Value。这是整个方案中最容易被忽视但也最关键的部分。Value必须是一个唯一值且必须由加锁的客户端生成和持有。通常我们可以使用UUID 线程ID或者更简单的使用Redisson这类客户端库时它们会生成一个UUID:threadId格式的字符串。为什么不能是固定的1或者locked因为在你释放锁的时候需要验证当前持有锁的是不是你自己。如果Value都一样客户端A在超时后锁被自动释放此时客户端B加锁成功紧接着客户端A执行完逻辑又来释放锁它用的是和B一样的Value就会错误地把客户端B的锁给释放掉。所以Value是客户端身份的证明。NX 键不存在时才设置。这是实现互斥性的核心。NX是“Not eXists”的缩写。只有当lock:order:1234这个Key在Redis中不存在时SET命令才会执行成功并将Value设置进去。如果这个Key已经存在意味着锁已被其他客户端持有那么本次SET操作将失败返回nil。这就保证了在同一时刻只有一个SET NX请求能成功创建这个Key即只有一个客户端能获得锁。PX 30000 设置键的过期时间毫秒。这是预防死锁的生命线。PX 30000表示这个Key在30000毫秒30秒后会自动过期并被Redis删除。为什么必须设置过期时间考虑一个场景客户端A成功加锁后在执行业务逻辑过程中宕机了或者发生了长时间的Full GC导致它永远无法主动来释放锁。如果没有过期时间这个锁就会永远留在Redis里其他所有客户端再也无法获得这个锁共享资源就被永久锁死了这就是死锁。设置一个合理的过期时间如30秒即使客户端崩溃锁也会在超时后自动释放系统具备了自我恢复的能力。把这四个部分组合起来这行命令的语义就是“尝试将一个具有客户端唯一标识的值设置到代表某个资源的键上前提是这个键必须不存在确保互斥并且无论后续发生什么这个键都将在30秒后自动消失防止死锁。” 这一行命令的调用本身是原子性的Redis保证它要么全部执行成功要么全部不执行不存在只设置了Key没设置过期时间的中间状态这是Redis单线程命令处理模型带来的天然优势。3. 获取锁与释放锁一个完整的流程与代码实现理解了核心命令我们来看一个完整的加锁、解锁流程应该如何实现。这里我用Java代码示例并会指出每个步骤的意图和潜在风险。3.1 加锁实现加锁的逻辑相对直接就是尝试执行那行核心命令。import redis.clients.jedis.Jedis; public class SimpleRedisLock { private static final String LOCK_PREFIX lock:; private static final int DEFAULT_EXPIRE_TIME 30000; // 30秒 private static final String LOCK_SUCCESS OK; private Jedis jedis; // Redis连接 private String lockKey; private String requestId; // 客户端唯一标识 private int expireTime; public SimpleRedisLock(Jedis jedis, String resourceKey) { this.jedis jedis; this.lockKey LOCK_PREFIX resourceKey; this.requestId java.util.UUID.randomUUID().toString() - Thread.currentThread().getId(); this.expireTime DEFAULT_EXPIRE_TIME; } /** * 尝试获取分布式锁 * return 是否获取成功 */ public boolean tryLock() { // 关键的一行原子性操作 String result jedis.set(lockKey, requestId, NX, PX, expireTime); return LOCK_SUCCESS.equals(result); } }关键点分析连接管理 示例中为了简洁直接使用了Jedis对象。在生产环境中你需要从连接池中获取连接并在使用后正确归还避免连接泄漏。唯一标识生成requestId使用了UUID线程ID这在大多数场景下足以保证全局唯一。如果你的客户端可能会在多个进程间共享则需要更复杂的标识比如加上进程ID。返回值判断jedis.set命令在成功时返回字符串OK失败时返回null。判断LOCK_SUCCESS.equals(result)是标准的成功判定方式。3.2 释放锁实现——踩坑重灾区释放锁的逻辑比加锁要复杂得多也是90%的坑所在。最天真的做法是直接DEL key这会导致我们前面说的误删其他客户端锁的问题。正确的做法是先验证再删除。而且这两个操作必须是原子的。错误示范非原子操作public void unlockWrong() { // 第一步获取当前锁的Value String currentValue jedis.get(lockKey); // 第二步判断是不是自己的锁 if (requestId.equals(currentValue)) { // 第三步如果是则删除锁 jedis.del(lockKey); } }这个逻辑在单线程下看起来没问题但在分布式并发下存在严重问题。考虑以下时序客户端A执行完if判断确认currentValue等于自己的requestId准备执行del。就在此时锁因为过期时间到了被Redis自动删除。客户端B趁虚而入成功执行SET NX PX获取了锁。客户端A继续执行调用了del命令结果把客户端B刚创建的锁给删除了问题的根源在于“判断-删除”这两个操作不是原子的中间可能被其他客户端插入操作。为了解决这个问题我们需要借助Lua脚本因为Redis执行Lua脚本时是原子性的不会被其他命令打断。正确实现使用Lua脚本public class SimpleRedisLock { // ... 其他代码同上 ... private static final String UNLOCK_SCRIPT if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; /** * 释放分布式锁 * return 是否释放成功成功删除返回true锁已不属于自己或不存在返回false */ public boolean unlock() { try { // 使用Lua脚本保证原子性比较并删除 Object result jedis.eval(UNLOCK_SCRIPT, 1, lockKey, requestId); // Lua脚本返回删除的键数量成功为1失败为0 return Long.valueOf(1L).equals(result); } catch (Exception e) { // 记录日志但通常不抛出异常避免影响主业务逻辑 e.printStackTrace(); return false; } } }关键点分析Lua脚本的原子性jedis.eval会将整个Lua脚本发送到Redis服务器服务器会一次性执行完整个脚本。在脚本执行期间不会有其他命令被执行从而完美解决了“判断-删除”的竞态条件问题。脚本逻辑 脚本首先用get命令获取锁当前的Value然后与传入的ARGV[1]即客户端的requestId进行比较。如果相等证明锁还是自己持有的则执行del删除并返回1如果不相等说明锁可能已经过期被其他客户端获取或者已经被释放此时返回0不做任何操作。异常处理 释放锁的操作不应该因为Redis网络波动等问题而抛出异常导致主业务流程中断。通常的做法是捕获异常记录日志并返回释放失败。调用方可以根据业务重要性决定是否告警或重试。返回值意义 返回true表示锁被成功释放由本客户端删除返回false表示释放操作未执行因为锁不属于本客户端。这给了调用方一个清晰的反馈。4. 超时与续约SET NX方案的核心挑战与应对即使我们正确地实现了加锁和释放锁SET NX PX方案依然面临一个本质性的挑战业务逻辑执行时间的不确定性与锁过期时间的确定性之间的矛盾。我们设定了30秒的过期时间PX 30000。这意味着从锁获取成功那一刻起一个30秒的倒计时就开始了。理想情况下客户端在30秒内完成业务逻辑并释放锁。但现实是骨感的业务逻辑可能很复杂涉及多个数据库操作、RPC调用。网络可能突然变慢下游服务响应延迟。服务器可能发生Full GC导致所有线程暂停数秒。如果业务逻辑执行时间超过了30秒会发生什么Redis会在第30秒准时把锁删除。此时客户端A还在懵懂地处理业务而锁已经没了。客户端B可以成功获取到锁并开始操作共享资源。于是客户端A和客户端B同时进入了临界区分布式锁失效了。这就是SET NX方案最经典的问题。为了解决它业界提出了“看门狗”Watchdog机制或者叫锁续约Lock Renewal。4.1 看门狗机制的原理看门狗机制的核心思想是在客户端持有锁期间启动一个后台守护线程定期比如每隔过期时间的1/3去检查锁是否还存在且仍属于自己如果是则刷新锁的过期时间。这个过程就像养了一只狗它每隔一段时间就“吠叫”一次执行续约操作告诉Redis“我还活着别删我的锁”如果客户端进程崩溃了看门狗线程也随之停止“吠叫”中断锁最终还是会因过期而被自动清理。一个简单的看门狗实现思路成功获取锁后启动一个定时任务ScheduledExecutorService。定时任务每隔10秒假设锁过期时间为30秒执行一次。每次执行时向Redis发送一个Lua脚本。这个脚本的逻辑是如果锁存在且Value匹配则重新设置过期时间为30秒pexpire命令。当客户端主动释放锁时除了删除Redis中的Key还要取消这个定时任务。4.2 实现锁续约的Lua脚本续约操作同样必须是原子的也需要Lua脚本因为它包含了“判断”和“设置”两个操作。-- KEYS[1] 锁的key -- ARGV[1] 客户端唯一标识 -- ARGV[2] 新的过期时间毫秒 if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(pexpire, KEYS[1], ARGV[2]) else return 0 end这个脚本先检查锁的持有者是否还是自己如果是则用pexpire命令重置过期时间如果不是则返回0表示续约失败可能锁已经丢失。注意 引入看门狗大大增加了方案的复杂性。你需要管理后台线程的生命周期确保在锁释放或客户端关闭时能正确停止续约避免资源泄漏。因此在实际生产中除非必要更推荐的做法是合理评估并设置一个足够长的过期时间让业务逻辑在绝大多数情况下都能在这个时间内完成。同时业务代码层面要做好幂等性设计即使出现极端情况下的锁失效也能通过幂等性来保证数据最终正确。5. 锁的可重入性在分布式场景下的考量可重入锁指的是同一个线程可以多次获取同一把锁而不会造成死锁。在单机ReentrantLock中这是通过一个计数器实现的。在分布式锁中我们是否也需要实现可重入性这取决于你的业务场景。如果你的一个方法methodA()内部调用了另一个需要同一把锁的methodB()而这两个方法在同一个线程执行流里那么就需要可重入锁。否则线程在methodA里获得锁后进入methodB再次尝试获取锁如果锁不可重入就会发生死锁——线程等待自己释放锁。为Redis锁增加可重入性需要在Value上做文章。不能只存客户端标识还需要存储一个重入计数器。一种简单的实现思路Value结构 将Value设计为clientUUID:threadId:count的格式例如f81d4fae-7dec-11d0-a765-00a0c91e6bf6-1:3末尾的3就是重入次数。加锁逻辑首先用GET命令查看锁是否存在。如果不存在则执行SET NX PXValue设置为clientUUID:threadId:1。如果存在则解析出Value中的客户端标识和重入次数。如果是当前客户端则将重入次数1并用SET命令不带NX更新回去同时刷新过期时间这一步也需要Lua脚本保证原子性。释放锁逻辑获取当前锁的Value。如果是当前客户端则将重入次数-1。如果减1后次数大于0则更新Value和过期时间。如果减1后次数等于0则删除Key。可以看到实现可重入性会让加锁和释放锁的逻辑变得复杂很多每一次操作都可能需要GET、判断、SET/DEL并且必须用Lua脚本包装以保证原子性。因此我的建议是除非业务逻辑明确存在嵌套加锁的需求否则优先考虑通过代码设计来避免嵌套调用分布式锁。例如将需要加锁的公共逻辑抽取成一个方法让methodA和methodB都调用这个公共方法而不是相互调用。这样可以大大简化分布式锁的实现和维护成本。像Redisson这样的成熟客户端库提供了可重入锁的实现如果确实需要直接使用这些库是更稳妥的选择。6. 高可用与集群环境下的新问题Redlock算法简介我们之前的讨论都基于一个前提Redis是单点或者是一个普通的主从架构。但在生产环境中为了高可用我们通常会使用Redis Sentinel哨兵或者Redis Cluster集群。这给分布式锁带来了新的挑战主从异步复制导致的数据丢失问题。考虑以下场景客户端A在Redis主节点Master上成功执行SET NX PX获得了锁。在主节点将这条数据异步复制给从节点Slave之前主节点宕机了。哨兵机制触发其中一个从节点被提升为新的主节点。但是这个新的主节点上没有客户端A刚才设置的那个锁Key此时客户端B向新的主节点申请同一把锁SET NX会成功。于是客户端A和客户端B都认为自己持有了锁冲突再次发生。为了解决这个问题Redis的作者Antirez提出了Redlock算法。它的核心思想是不再依赖单个Redis实例而是同时向多个独立的Redis实例主节点申请锁只有当超过半数的实例都成功获得锁时才算加锁成功。Redlock算法简要步骤获取当前时间毫秒。依次向N个独立的Redis实例发送加锁命令SET NX PX并设置一个远小于锁超时时间的网络超时时间例如5-50ms避免长时间阻塞。计算整个加锁过程消耗的时间。只有当客户端在大多数N/2 1实例上加锁成功且总耗时小于锁的有效时间时锁才获取成功。如果锁获取成功其有效时间需要重新计算初始有效时间减去加锁过程消耗的时间。如果锁获取失败要么未获得多数票要么总耗时已超客户端需要向所有Redis实例发送释放锁的Lua脚本。Redlock算法通过引入多节点和多数派机制提高了锁在部分节点故障时的可靠性。但是它也带来了显著的复杂性需要部署多个独立的Redis主节点通常建议5个客户端逻辑变得复杂性能也有所下降需要多次网络往返。此外关于Redlock是否绝对安全在分布式系统社区也有激烈的讨论涉及系统时钟跳跃等极端情况。因此对于大多数业务场景如果你的业务可以容忍在Redis主从故障切换的极短时间内出现锁失效比如通过幂等性兜底那么使用单Redis节点或主从架构配合合理的超时时间是一个更简单实用的选择。如果你的业务对锁的强一致性要求极高且愿意承担复杂性和性能开销那么可以考虑实现或使用支持Redlock的客户端如Redisson。7. 实践总结与选型建议经过上面的拆解我们可以看到一个简单的SET NX PX命令背后是一个完整的分布式锁解决方案的冰山一角。在实际项目中我的经验是评估需求避免过度设计 首先问自己是否真的需要分布式锁是否可以用数据库乐观锁、状态机等更轻量的方式实现如果确实需要评估一下锁失效的后果是否严重。对于大多数秒杀扣库存、更新用户状态等场景配合业务幂等性即使出现极短时间的锁失效也是可以接受的。优先使用成熟客户端库 不要重复造轮子。对于Java技术栈Redisson是首选。它提供了可重入锁、公平锁、联锁、红锁等多种锁实现内置了看门狗机制处理了所有复杂的原子性和续约逻辑并且与Spring框架集成良好。使用它你只需要关注业务逻辑而不用操心锁的实现细节。类似地其他语言也有优秀的客户端如go-redsyncfor Go。如果非要自己实现务必做到Value唯一 使用客户端唯一标识。释放原子 使用Lua脚本比较并删除。设置超时 必须设置一个合理的过期时间并充分考虑业务执行时间。异常处理 加锁失败、释放锁异常要有降级或日志记录不能影响主流程。关于超时时间 这是一个权衡。设置太短容易因业务未完成而锁提前释放导致并发问题。设置太长一旦客户端宕机资源被锁定的时间也长影响系统可用性。一个好的实践是通过压测和监控统计出业务逻辑在99%情况下的最长耗时以此为基础再增加一定的缓冲时间比如50%作为锁的超时时间。监控与告警 对分布式锁的关键指标进行监控如锁的获取成功率、平均等待时间、锁持有时间等。如果发现锁竞争激烈获取失败率高或持有时间异常长需要及时告警并排查原因可能是业务逻辑瓶颈或死循环。分布式锁是一个看似简单实则深邃的话题SET NX是它的起点但绝不是终点。理解其背后的原理、局限性和演进方案能帮助我们在不同的业务场景下做出更合适的技术选型构建出更健壮的系统。 Redis分布式锁深度解析：从SET NX原理到生产实践全攻略
1. 从单机锁到分布式锁为什么我们需要Redis Set NX在单机应用的时代处理并发资源竞争我们通常会想到Java里的synchronized关键字或者ReentrantLock。这些锁机制在单个JVM进程内运行得非常好因为它们依赖于进程内的内存状态来协调线程。但是当你的应用从一台服务器扩展到两台、十台甚至上百台服务器时情况就完全变了。想象一下一个商品秒杀活动库存扣减的逻辑部署在十台服务器上如果还用synchronized那它只能锁住自己这台服务器上的线程其他九台服务器的请求依然会一拥而上导致库存超卖。这就是典型的分布式环境下的并发问题。分布式锁就是为了解决这个问题而生的。它的核心目标是在分布式系统这个“无共享内存”的多个进程或主机之间提供一种互斥机制确保在同一时间只有一个客户端能对某个共享资源进行操作。实现分布式锁的方案有很多比如基于数据库的唯一索引、基于ZooKeeper的临时有序节点而基于Redis的实现因其高性能和相对简单的模型成为了最流行的选择之一。在Redis的众多命令中SET命令配合NX和PX参数是实现分布式锁最基础、最经典的方式。SET key value NX PX 30000这一行简单的命令几乎成了面试中关于分布式锁的“开场白”。它看起来简单但背后涉及了原子性、锁超时、死锁预防等一系列关键问题。很多人觉得会用这行命令就等于懂了分布式锁但实际生产环境中仅仅知道这行命令是远远不够的从锁的获取、持有到释放每一个环节都藏着“坑”。这篇文章我就结合自己这些年趟过的雷从头到尾拆解一下用RedisSET NX实现分布式锁的完整逻辑、那些容易忽略的细节以及如何让它变得更健壮。2. SET NX PX一行命令背后的精妙设计我们先来彻底理解这行核心命令SET lock:order:1234 client_unique_id NX PX 30000。我们把它拆开看每一个部分都不是多余的。lock:order:1234 锁的Key。这是锁的唯一标识必须与你要保护的资源强关联。比如保护订单ID为1234的订单Key就应该是lock:order:1234。这里有个最佳实践使用业务前缀如lock:这样在Redis可视化工具里一目了然也便于后续的监控和管理。Key的设计要保证全局唯一性避免不同业务间的锁意外冲突。client_unique_id 锁的Value。这是整个方案中最容易被忽视但也最关键的部分。Value必须是一个唯一值且必须由加锁的客户端生成和持有。通常我们可以使用UUID 线程ID或者更简单的使用Redisson这类客户端库时它们会生成一个UUID:threadId格式的字符串。为什么不能是固定的1或者locked因为在你释放锁的时候需要验证当前持有锁的是不是你自己。如果Value都一样客户端A在超时后锁被自动释放此时客户端B加锁成功紧接着客户端A执行完逻辑又来释放锁它用的是和B一样的Value就会错误地把客户端B的锁给释放掉。所以Value是客户端身份的证明。NX 键不存在时才设置。这是实现互斥性的核心。NX是“Not eXists”的缩写。只有当lock:order:1234这个Key在Redis中不存在时SET命令才会执行成功并将Value设置进去。如果这个Key已经存在意味着锁已被其他客户端持有那么本次SET操作将失败返回nil。这就保证了在同一时刻只有一个SET NX请求能成功创建这个Key即只有一个客户端能获得锁。PX 30000 设置键的过期时间毫秒。这是预防死锁的生命线。PX 30000表示这个Key在30000毫秒30秒后会自动过期并被Redis删除。为什么必须设置过期时间考虑一个场景客户端A成功加锁后在执行业务逻辑过程中宕机了或者发生了长时间的Full GC导致它永远无法主动来释放锁。如果没有过期时间这个锁就会永远留在Redis里其他所有客户端再也无法获得这个锁共享资源就被永久锁死了这就是死锁。设置一个合理的过期时间如30秒即使客户端崩溃锁也会在超时后自动释放系统具备了自我恢复的能力。把这四个部分组合起来这行命令的语义就是“尝试将一个具有客户端唯一标识的值设置到代表某个资源的键上前提是这个键必须不存在确保互斥并且无论后续发生什么这个键都将在30秒后自动消失防止死锁。” 这一行命令的调用本身是原子性的Redis保证它要么全部执行成功要么全部不执行不存在只设置了Key没设置过期时间的中间状态这是Redis单线程命令处理模型带来的天然优势。3. 获取锁与释放锁一个完整的流程与代码实现理解了核心命令我们来看一个完整的加锁、解锁流程应该如何实现。这里我用Java代码示例并会指出每个步骤的意图和潜在风险。3.1 加锁实现加锁的逻辑相对直接就是尝试执行那行核心命令。import redis.clients.jedis.Jedis; public class SimpleRedisLock { private static final String LOCK_PREFIX lock:; private static final int DEFAULT_EXPIRE_TIME 30000; // 30秒 private static final String LOCK_SUCCESS OK; private Jedis jedis; // Redis连接 private String lockKey; private String requestId; // 客户端唯一标识 private int expireTime; public SimpleRedisLock(Jedis jedis, String resourceKey) { this.jedis jedis; this.lockKey LOCK_PREFIX resourceKey; this.requestId java.util.UUID.randomUUID().toString() - Thread.currentThread().getId(); this.expireTime DEFAULT_EXPIRE_TIME; } /** * 尝试获取分布式锁 * return 是否获取成功 */ public boolean tryLock() { // 关键的一行原子性操作 String result jedis.set(lockKey, requestId, NX, PX, expireTime); return LOCK_SUCCESS.equals(result); } }关键点分析连接管理 示例中为了简洁直接使用了Jedis对象。在生产环境中你需要从连接池中获取连接并在使用后正确归还避免连接泄漏。唯一标识生成requestId使用了UUID线程ID这在大多数场景下足以保证全局唯一。如果你的客户端可能会在多个进程间共享则需要更复杂的标识比如加上进程ID。返回值判断jedis.set命令在成功时返回字符串OK失败时返回null。判断LOCK_SUCCESS.equals(result)是标准的成功判定方式。3.2 释放锁实现——踩坑重灾区释放锁的逻辑比加锁要复杂得多也是90%的坑所在。最天真的做法是直接DEL key这会导致我们前面说的误删其他客户端锁的问题。正确的做法是先验证再删除。而且这两个操作必须是原子的。错误示范非原子操作public void unlockWrong() { // 第一步获取当前锁的Value String currentValue jedis.get(lockKey); // 第二步判断是不是自己的锁 if (requestId.equals(currentValue)) { // 第三步如果是则删除锁 jedis.del(lockKey); } }这个逻辑在单线程下看起来没问题但在分布式并发下存在严重问题。考虑以下时序客户端A执行完if判断确认currentValue等于自己的requestId准备执行del。就在此时锁因为过期时间到了被Redis自动删除。客户端B趁虚而入成功执行SET NX PX获取了锁。客户端A继续执行调用了del命令结果把客户端B刚创建的锁给删除了问题的根源在于“判断-删除”这两个操作不是原子的中间可能被其他客户端插入操作。为了解决这个问题我们需要借助Lua脚本因为Redis执行Lua脚本时是原子性的不会被其他命令打断。正确实现使用Lua脚本public class SimpleRedisLock { // ... 其他代码同上 ... private static final String UNLOCK_SCRIPT if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; /** * 释放分布式锁 * return 是否释放成功成功删除返回true锁已不属于自己或不存在返回false */ public boolean unlock() { try { // 使用Lua脚本保证原子性比较并删除 Object result jedis.eval(UNLOCK_SCRIPT, 1, lockKey, requestId); // Lua脚本返回删除的键数量成功为1失败为0 return Long.valueOf(1L).equals(result); } catch (Exception e) { // 记录日志但通常不抛出异常避免影响主业务逻辑 e.printStackTrace(); return false; } } }关键点分析Lua脚本的原子性jedis.eval会将整个Lua脚本发送到Redis服务器服务器会一次性执行完整个脚本。在脚本执行期间不会有其他命令被执行从而完美解决了“判断-删除”的竞态条件问题。脚本逻辑 脚本首先用get命令获取锁当前的Value然后与传入的ARGV[1]即客户端的requestId进行比较。如果相等证明锁还是自己持有的则执行del删除并返回1如果不相等说明锁可能已经过期被其他客户端获取或者已经被释放此时返回0不做任何操作。异常处理 释放锁的操作不应该因为Redis网络波动等问题而抛出异常导致主业务流程中断。通常的做法是捕获异常记录日志并返回释放失败。调用方可以根据业务重要性决定是否告警或重试。返回值意义 返回true表示锁被成功释放由本客户端删除返回false表示释放操作未执行因为锁不属于本客户端。这给了调用方一个清晰的反馈。4. 超时与续约SET NX方案的核心挑战与应对即使我们正确地实现了加锁和释放锁SET NX PX方案依然面临一个本质性的挑战业务逻辑执行时间的不确定性与锁过期时间的确定性之间的矛盾。我们设定了30秒的过期时间PX 30000。这意味着从锁获取成功那一刻起一个30秒的倒计时就开始了。理想情况下客户端在30秒内完成业务逻辑并释放锁。但现实是骨感的业务逻辑可能很复杂涉及多个数据库操作、RPC调用。网络可能突然变慢下游服务响应延迟。服务器可能发生Full GC导致所有线程暂停数秒。如果业务逻辑执行时间超过了30秒会发生什么Redis会在第30秒准时把锁删除。此时客户端A还在懵懂地处理业务而锁已经没了。客户端B可以成功获取到锁并开始操作共享资源。于是客户端A和客户端B同时进入了临界区分布式锁失效了。这就是SET NX方案最经典的问题。为了解决它业界提出了“看门狗”Watchdog机制或者叫锁续约Lock Renewal。4.1 看门狗机制的原理看门狗机制的核心思想是在客户端持有锁期间启动一个后台守护线程定期比如每隔过期时间的1/3去检查锁是否还存在且仍属于自己如果是则刷新锁的过期时间。这个过程就像养了一只狗它每隔一段时间就“吠叫”一次执行续约操作告诉Redis“我还活着别删我的锁”如果客户端进程崩溃了看门狗线程也随之停止“吠叫”中断锁最终还是会因过期而被自动清理。一个简单的看门狗实现思路成功获取锁后启动一个定时任务ScheduledExecutorService。定时任务每隔10秒假设锁过期时间为30秒执行一次。每次执行时向Redis发送一个Lua脚本。这个脚本的逻辑是如果锁存在且Value匹配则重新设置过期时间为30秒pexpire命令。当客户端主动释放锁时除了删除Redis中的Key还要取消这个定时任务。4.2 实现锁续约的Lua脚本续约操作同样必须是原子的也需要Lua脚本因为它包含了“判断”和“设置”两个操作。-- KEYS[1] 锁的key -- ARGV[1] 客户端唯一标识 -- ARGV[2] 新的过期时间毫秒 if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(pexpire, KEYS[1], ARGV[2]) else return 0 end这个脚本先检查锁的持有者是否还是自己如果是则用pexpire命令重置过期时间如果不是则返回0表示续约失败可能锁已经丢失。注意 引入看门狗大大增加了方案的复杂性。你需要管理后台线程的生命周期确保在锁释放或客户端关闭时能正确停止续约避免资源泄漏。因此在实际生产中除非必要更推荐的做法是合理评估并设置一个足够长的过期时间让业务逻辑在绝大多数情况下都能在这个时间内完成。同时业务代码层面要做好幂等性设计即使出现极端情况下的锁失效也能通过幂等性来保证数据最终正确。5. 锁的可重入性在分布式场景下的考量可重入锁指的是同一个线程可以多次获取同一把锁而不会造成死锁。在单机ReentrantLock中这是通过一个计数器实现的。在分布式锁中我们是否也需要实现可重入性这取决于你的业务场景。如果你的一个方法methodA()内部调用了另一个需要同一把锁的methodB()而这两个方法在同一个线程执行流里那么就需要可重入锁。否则线程在methodA里获得锁后进入methodB再次尝试获取锁如果锁不可重入就会发生死锁——线程等待自己释放锁。为Redis锁增加可重入性需要在Value上做文章。不能只存客户端标识还需要存储一个重入计数器。一种简单的实现思路Value结构 将Value设计为clientUUID:threadId:count的格式例如f81d4fae-7dec-11d0-a765-00a0c91e6bf6-1:3末尾的3就是重入次数。加锁逻辑首先用GET命令查看锁是否存在。如果不存在则执行SET NX PXValue设置为clientUUID:threadId:1。如果存在则解析出Value中的客户端标识和重入次数。如果是当前客户端则将重入次数1并用SET命令不带NX更新回去同时刷新过期时间这一步也需要Lua脚本保证原子性。释放锁逻辑获取当前锁的Value。如果是当前客户端则将重入次数-1。如果减1后次数大于0则更新Value和过期时间。如果减1后次数等于0则删除Key。可以看到实现可重入性会让加锁和释放锁的逻辑变得复杂很多每一次操作都可能需要GET、判断、SET/DEL并且必须用Lua脚本包装以保证原子性。因此我的建议是除非业务逻辑明确存在嵌套加锁的需求否则优先考虑通过代码设计来避免嵌套调用分布式锁。例如将需要加锁的公共逻辑抽取成一个方法让methodA和methodB都调用这个公共方法而不是相互调用。这样可以大大简化分布式锁的实现和维护成本。像Redisson这样的成熟客户端库提供了可重入锁的实现如果确实需要直接使用这些库是更稳妥的选择。6. 高可用与集群环境下的新问题Redlock算法简介我们之前的讨论都基于一个前提Redis是单点或者是一个普通的主从架构。但在生产环境中为了高可用我们通常会使用Redis Sentinel哨兵或者Redis Cluster集群。这给分布式锁带来了新的挑战主从异步复制导致的数据丢失问题。考虑以下场景客户端A在Redis主节点Master上成功执行SET NX PX获得了锁。在主节点将这条数据异步复制给从节点Slave之前主节点宕机了。哨兵机制触发其中一个从节点被提升为新的主节点。但是这个新的主节点上没有客户端A刚才设置的那个锁Key此时客户端B向新的主节点申请同一把锁SET NX会成功。于是客户端A和客户端B都认为自己持有了锁冲突再次发生。为了解决这个问题Redis的作者Antirez提出了Redlock算法。它的核心思想是不再依赖单个Redis实例而是同时向多个独立的Redis实例主节点申请锁只有当超过半数的实例都成功获得锁时才算加锁成功。Redlock算法简要步骤获取当前时间毫秒。依次向N个独立的Redis实例发送加锁命令SET NX PX并设置一个远小于锁超时时间的网络超时时间例如5-50ms避免长时间阻塞。计算整个加锁过程消耗的时间。只有当客户端在大多数N/2 1实例上加锁成功且总耗时小于锁的有效时间时锁才获取成功。如果锁获取成功其有效时间需要重新计算初始有效时间减去加锁过程消耗的时间。如果锁获取失败要么未获得多数票要么总耗时已超客户端需要向所有Redis实例发送释放锁的Lua脚本。Redlock算法通过引入多节点和多数派机制提高了锁在部分节点故障时的可靠性。但是它也带来了显著的复杂性需要部署多个独立的Redis主节点通常建议5个客户端逻辑变得复杂性能也有所下降需要多次网络往返。此外关于Redlock是否绝对安全在分布式系统社区也有激烈的讨论涉及系统时钟跳跃等极端情况。因此对于大多数业务场景如果你的业务可以容忍在Redis主从故障切换的极短时间内出现锁失效比如通过幂等性兜底那么使用单Redis节点或主从架构配合合理的超时时间是一个更简单实用的选择。如果你的业务对锁的强一致性要求极高且愿意承担复杂性和性能开销那么可以考虑实现或使用支持Redlock的客户端如Redisson。7. 实践总结与选型建议经过上面的拆解我们可以看到一个简单的SET NX PX命令背后是一个完整的分布式锁解决方案的冰山一角。在实际项目中我的经验是评估需求避免过度设计 首先问自己是否真的需要分布式锁是否可以用数据库乐观锁、状态机等更轻量的方式实现如果确实需要评估一下锁失效的后果是否严重。对于大多数秒杀扣库存、更新用户状态等场景配合业务幂等性即使出现极短时间的锁失效也是可以接受的。优先使用成熟客户端库 不要重复造轮子。对于Java技术栈Redisson是首选。它提供了可重入锁、公平锁、联锁、红锁等多种锁实现内置了看门狗机制处理了所有复杂的原子性和续约逻辑并且与Spring框架集成良好。使用它你只需要关注业务逻辑而不用操心锁的实现细节。类似地其他语言也有优秀的客户端如go-redsyncfor Go。如果非要自己实现务必做到Value唯一 使用客户端唯一标识。释放原子 使用Lua脚本比较并删除。设置超时 必须设置一个合理的过期时间并充分考虑业务执行时间。异常处理 加锁失败、释放锁异常要有降级或日志记录不能影响主流程。关于超时时间 这是一个权衡。设置太短容易因业务未完成而锁提前释放导致并发问题。设置太长一旦客户端宕机资源被锁定的时间也长影响系统可用性。一个好的实践是通过压测和监控统计出业务逻辑在99%情况下的最长耗时以此为基础再增加一定的缓冲时间比如50%作为锁的超时时间。监控与告警 对分布式锁的关键指标进行监控如锁的获取成功率、平均等待时间、锁持有时间等。如果发现锁竞争激烈获取失败率高或持有时间异常长需要及时告警并排查原因可能是业务逻辑瓶颈或死循环。分布式锁是一个看似简单实则深邃的话题SET NX是它的起点但绝不是终点。理解其背后的原理、局限性和演进方案能帮助我们在不同的业务场景下做出更合适的技术选型构建出更健壮的系统。