当前位置：首页 > news >正文

Redis分布式锁演进全解析

news 2025/10/27 15:26:30

在分布式系统中，并发控制是绕不开的核心问题。当多个服务实例同时操作共享资源（如库存扣减、订单创建）时，必须通过分布式锁保证操作的原子性。而Redis凭借其高性能、高可用的特性，成为实现分布式锁的主流选择之一。

但Redis分布式锁并非“一蹴而就”，从最简陋的实现到能支撑高并发的生产级方案，经历了多次关键演进。

一、0.1版本：最基础的实现——setnx+expire组合

要实现分布式锁，核心需求有两个：独占性（同一时间只有一个线程能拿到锁）和防死锁（避免线程拿到锁后因异常崩溃导致锁永远无法释放）。基于这两个需求，最直观的实现就是用Redis的setnx和expire命令组合。

1.1 实现逻辑

setnx（set if not exists）命令的特性是：如果key不存在则设置成功并返回1（表示拿到锁），如果key已存在则设置失败并返回0（表示未拿到锁），这天然满足“独占性”需求；expire命令则用于给锁设置过期时间，避免线程拿到锁后异常崩溃导致死锁，满足“防死锁”需求。

代码实现（伪代码）如下：


// 加锁逻辑
if (redisClient.setnx(lockKey, lockValue)) {  // setnx成功，拿到锁redisClient.expire(lockKey, 1000);  // 设置1秒过期时间try {// 执行核心业务逻辑doSomething();} catch (Exception e) {log.error("业务执行异常", e);} finally {// 释放锁：直接删除keyredisClient.del(lockKey);}
} else {// 未拿到锁，执行重试或返回失败逻辑return "获取锁失败，请重试";
}

1.2 致命缺陷：原子性问题

这个版本看似满足了核心需求，但存在一个致命问题：setnx和expire是两个独立命令，不具备原子性。在极端场景下，会导致死锁：

线程A执行setnx成功，拿到锁；
线程A在执行expire命令前，服务突然宕机、重启或网络中断；
此时lockKey已存在，但未设置过期时间，后续所有线程都无法通过setnx拿到锁，形成死锁。

核心问题：分布式系统中，两个独立命令之间可能存在“时间窗口”，极端情况下会导致逻辑异常。解决这类问题的核心思路是“将多个命令原子化”。

二、0.2版本：原子化优化——SET扩展命令

针对0.1版本的原子性问题，有两种优化思路：一是用Lua脚本将setnx和expire封装成一个原子操作；二是使用Redis的SET扩展命令，后者更简洁高效。

2.1 关键优化：SET命令的原子性扩展

Redis 2.6.12版本后，SET命令支持多参数扩展，语法如下：


SET key value [EX seconds] [PX milliseconds] [NX|XX]

各参数含义：

EX seconds：设置key的过期时间（秒），等价于expire命令；
PX milliseconds：设置key的过期时间（毫秒）；
NX：仅当key不存在时才设置，等价于setnx命令；
XX：仅当key存在时才设置（与NX相反）。

最重要的是：这一个SET命令的所有参数是原子执行的，不存在“设置成功但未过期”的中间状态，从根本上解决了0.1版本的原子性问题。

2.2 优化后代码实现


// 加锁逻辑：使用SET扩展命令实现原子操作
if (redisClient.set(lockKey, lockValue, "NX", "EX", 1000)) {  // NX保证独占，EX设置1秒过期try {// 执行核心业务逻辑doSomething();} catch (Exception e) {log.error("业务执行异常", e);} finally {// 释放锁：直接删除keyredisClient.del(lockKey);}
} else {return "获取锁失败，请重试";
}

2.3 新的缺陷：“误删锁”问题

0.2版本解决了原子性和死锁问题，但释放锁的逻辑存在新的隐患——线程可能误删其他线程的锁，具体场景如下：

线程A拿到锁，设置过期时间1秒；
线程A的业务逻辑执行耗时超过1秒（如网络延迟、GC卡顿），锁因过期自动释放；
线程B此时拿到同一把锁，开始执行业务；
线程A的业务逻辑执行完成，进入finally块，执行del命令删除锁；
此时线程A删除的是线程B持有的锁，导致线程B的锁被“误删”，后续其他线程（如线程C）可以拿到锁，出现“多个线程同时持有锁”的情况，破坏独占性。

核心问题：释放锁时没有校验“锁的归属权”，任何线程都可以删除lockKey。

三、0.3版本：归属权校验——唯一值+原子释放

要解决“误删锁”问题，核心思路是：给锁加上“归属标识”，释放锁前先校验标识是否属于自己，只有归属者才能释放锁。同时，校验和释放操作必须原子化，避免新的时间窗口问题。

3.1 关键优化：锁值唯一化+Lua脚本释放

锁值唯一化：加锁时，将lockValue设置为一个全局唯一的值（如UUID、线程ID+时间戳），作为锁的“归属标识”；
释放锁原子化：用Lua脚本封装“校验归属权+删除锁”的逻辑，确保这两个操作原子执行（Redis执行Lua脚本时会阻塞其他命令，保证原子性）。

3.2 优化后代码实现


// 生成全局唯一的锁值（归属标识）
String lockValue = UUID.randomUUID().toString() + ":" + Thread.currentThread().getId();
// 加锁：NX保证独占，EX设置1秒过期，lockValue为唯一归属标识
if (redisClient.set(lockKey, lockValue, "NX", "EX", 1000)) {try {// 执行核心业务逻辑doSomething();} catch (Exception e) {log.error("业务执行异常", e);} finally {// 释放锁：用Lua脚本原子化执行“校验+删除”String luaScript = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";redisClient.eval(luaScript, Collections.singletonList(lockKey), Collections.singletonList(lockValue));}
} else {return "获取锁失败，请重试";
}

Lua脚本逻辑解析：

通过redis.call('get', KEYS[1])获取当前锁值；
对比锁值与ARGV[1]（当前线程的lockValue），若一致则执行del删除锁，返回1；
若不一致则返回0，不执行删除操作，避免误删其他线程的锁。

3.3 局限性：锁过期与业务未完成的矛盾

0.3版本已经能满足大多数中小并发场景的需求，但在高并发或业务耗时不稳定的场景下，仍存在一个核心矛盾：锁的过期时间难以精准设置。

如果过期时间设置太短，可能导致业务未执行完锁就自动释放；如果设置太长，一旦线程异常崩溃，锁释放的时间会过长，降低系统并发度。例如：

设置过期时间5秒，但某次业务因GC卡顿执行了6秒，锁会提前释放，导致并发问题；
设置过期时间30秒，若线程拿到锁后服务宕机，30秒内其他线程都无法拿到锁，系统吞吐量下降。

解决这个矛盾的核心思路是“动态续期”——让持有锁的线程在业务执行过程中，定期给锁延长过期时间，确保业务执行完前锁不会过期。这就是“看门狗”机制的核心原理。

四、生产级方案：Redisson框架的完美落地

0.3版本的局限性需要手动实现“动态续期”“重试机制”“高可用”等复杂逻辑，而Redisson框架已经将这些生产级特性封装完毕，成为Redis分布式锁的首选方案。

4.1 核心特性：看门狗机制

Redisson的“看门狗”（Watch Dog）机制会自动为持有锁的线程续期：

线程拿到锁后，Redisson会启动一个后台线程（看门狗）；
看门狗会每隔“锁过期时间的1/3”（默认过期时间30秒，续期间隔10秒）检查一次；
若线程仍持有锁且业务未执行完，看门狗会自动将锁的过期时间延长至30秒；
若线程执行完业务或异常崩溃，看门狗会停止续期，锁到期后自动释放。

4.2 Redisson分布式锁实现代码

引入Redisson依赖后，实现分布式锁的代码极其简洁：


// 1. 获取Redisson客户端实例
RedissonClient redissonClient = Redisson.create(config);
// 2. 获取锁对象（lockKey为锁的唯一标识）
RLock lock = redissonClient.getLock(lockKey);try {// 3. 加锁：默认30秒过期，支持自动续期（看门狗机制）// 可指定加锁等待时间和过期时间：lock.lock(10, 30, TimeUnit.SECONDS)lock.lock();// 4. 执行核心业务逻辑doSomething();
} catch (Exception e) {log.error("业务执行异常", e);
} finally {// 5. 释放锁：只有持有锁的线程能释放if (lock.isHeldByCurrentThread()) {lock.unlock();}
}

4.3 其他生产级特性

除了看门狗机制，Redisson还提供了满足复杂场景的核心特性：

可重入锁：支持同一线程多次加锁（避免死锁），底层通过“锁值+重入次数”实现；
公平锁：通过队列保证线程获取锁的顺序，避免“饥饿问题”（调用lockFair()方法）；
联锁/红锁：支持多Redis实例加锁，满足高可用需求（避免单实例故障导致锁失效）；
自动重试：加锁失败时会自动重试，可配置重试次数和间隔。

五、演进历程总结与面试考点

5.1 核心演进脉络

版本	实现方式	解决的问题	存在的缺陷
0.1	setnx + expire	实现基本的独占性和防死锁	setnx与expire非原子，可能死锁
0.2	SET NX EX命令	解决加锁的原子性问题	释放锁无归属校验，可能误删
0.3	唯一lockValue + Lua释放	解决误删锁问题	锁过期与业务耗时不匹配
生产级	Redisson框架	动态续期、可重入、高可用等	依赖第三方框架（非缺陷）