Redis 分布式锁：从原理到 Spring Boot 实战，避开 90% 开发者踩的坑！

视频看了几百小时还迷糊？关注我，几分钟让你秒懂！

在分布式系统中，多个服务实例同时操作共享资源（如扣减库存、生成订单号）时，必须使用分布式锁来保证数据一致性。而 Redis 凭借其高性能和原子操作，成为实现分布式锁的首选方案。

但！看似简单的SETNX，背后却隐藏着无数陷阱：锁失效、死锁、主从切换丢锁、误删他人锁……稍有不慎，轻则数据错乱，重则资损事故！

本文将带你：

• ✅ 深入理解 Redis 分布式锁的核心原理
• ✅ 用Java + Spring Boot实现高可用、可重入、防误删的分布式锁
• ✅ 揭露 4 大经典反例与生产级避坑指南

---

一、为什么需要分布式锁？

🎯 场景：电商秒杀扣库存

// 单机环境下，synchronized 足够 public void deductStock(Long productId) { synchronized (this) { int stock = getStockFromDB(productId); if (stock > 0) { updateStock(productId, stock - 1); // 扣减 } } }

❌问题：当部署多个服务实例（如 3 台服务器），synchronized只在 JVM 内生效，无法跨进程同步！

✅ 解决方案：Redis 分布式锁

• 所有实例竞争同一把“Redis 锁”
• 谁拿到锁，谁操作数据库
• 保证同一时间只有一个实例执行关键代码

---

二、基础版：SETNX + EXPIRE（❌ 有致命缺陷！）

❌ 反例 1：非原子操作 → 死锁风险

// 错误写法！ Boolean locked = redisTemplate.opsForValue().setIfAbsent("lock:order", "1"); if (locked) { // 设置过期时间（防止业务卡死导致锁永不过期） redisTemplate.expire("lock:order", 10, TimeUnit.SECONDS); try { // 执行业务... } finally { redisTemplate.delete("lock:order"); // 释放锁 } }

🔥 问题分析：

• setIfAbsent()和expire()是两个命令，非原子！
• 如果在setIfAbsent成功后、expire执行前，服务宕机 →锁永不过期 → 死锁！

---

三、正确姿势 1：SET 命令原子加锁（Redis 2.6.12+）

Redis 的SET命令支持NX（不存在才设） +EX/PX（自动过期）组合，原子性保证。

✅ Spring Boot 实现（基础版）

public boolean tryLock(String lockKey, String requestId, long expireTimeMs) { Boolean result = redisTemplate.execute( (RedisCallback<Boolean>) connection -> connection.set( lockKey.getBytes(), requestId.getBytes(), Expiration.milliseconds(expireTimeMs), RedisStringCommands.SetOption.SET_IF_ABSENT ) ); return Boolean.TRUE.equals(result); } public void unlock(String lockKey, String requestId) { // 注意：这里仍有问题！见下文 redisTemplate.delete(lockKey); }

📌关键点：

• requestId：建议用UUID + 线程ID，用于标识锁持有者
• expireTimeMs：必须设置，防止死锁

❌ 但！解锁仍有问题：可能误删他人锁！

假设：

• 服务 A 拿到锁，但业务执行超时（>10s），锁自动过期
• 服务 B 拿到同一把锁
• 此时服务 A 执行完，调用delete(lockKey)→删掉了服务 B 的锁！

---

四、正确姿势 2：Lua 脚本保证“判断+删除”原子性

要安全释放锁，必须满足：

只有锁的持有者（requestId 匹配）才能删除锁

这需要先 GET 判断值，再 DEL，但两步操作非原子 → 必须用Lua 脚本！

✅ 安全解锁 Lua 脚本

-- unlock.lua if redis.call("GET", KEYS[1]) == ARGV[1] then return redis.call("DEL", KEYS[1]) else return 0 end

✅ Spring Boot 集成

@Component public class RedisDistributedLock { @Autowired private StringRedisTemplate redisTemplate; private static final DefaultRedisScript<Long> UNLOCK_SCRIPT; static { UNLOCK_SCRIPT = new DefaultRedisScript<>(); UNLOCK_SCRIPT.setLocation(new ClassPathResource("lua/unlock.lua")); UNLOCK_SCRIPT.setResultType(Long.class); } public boolean tryLock(String lockKey, String requestId, long expireTimeMs) { Boolean result = redisTemplate.opsForValue() .setIfAbsent(lockQey, requestId, Duration.ofMillis(expireTimeMs)); return Boolean.TRUE.equals(result); } public void unlock(String lockKey, String requestId) { redisTemplate.execute(UNLOCK_SCRIPT, Collections.singletonList(lockKey), requestId); } }

✅优势：Lua 脚本在 Redis 中原子执行，杜绝误删！

---

五、进阶需求：可重入锁 & 自动续期

问题 1：同一线程能否多次获取同一把锁？（可重入）

• 场景：方法 A 加锁 → 调用方法 B（也需要同一把锁）
• 基础版会阻塞 → 需要可重入锁

问题 2：业务执行时间 > 锁过期时间？（自动续期）

• 如锁 TTL=30s，但业务需 60s → 锁提前释放 → 并发安全失效

✅ 解决方案：Redisson（生产推荐！）

Redisson是 Redis 官方推荐的 Java 客户端，内置可重入、自动续期、看门狗机制的分布式锁。

Maven 引入

<dependency> <groupId>org.redisson</groupId> <artifactId>redisson-spring-boot-starter</artifactId> <version>3.23.5</version> </dependency>

Spring Boot 使用

@Service public class OrderService { @Autowired private RedissonClient redissonClient; public void createOrder() { RLock lock = redissonClient.getLock("lock:order:create"); try { // 尝试加锁，最多等待 10 秒，上锁后 30 秒自动解锁 boolean locked = lock.tryLock(10, 30, TimeUnit.SECONDS); if (!locked) { throw new RuntimeException("获取锁失败"); } // 执行业务（即使超过 30 秒，Redisson 会自动续期！） doCreateOrder(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } finally { lock.unlock(); // 可重入：只有最外层 unlock 才真正释放 } } }

🌟Redisson 核心机制：

• 看门狗（Watchdog）：只要线程持有锁，每隔 10s 自动续期（TTL 重置为 30s）
• 可重入计数：同一线程多次加锁，内部计数器 +1，unlock 时 -1，归零才释放
• 公平锁/读写锁：支持更复杂场景

---

六、四大经典陷阱与避坑指南

陷阱	后果	解决方案
非原子加锁	死锁	用SET key val NX EX 10原子命令
无标识解锁	误删他人锁	用 Lua 脚本校验 requestId
锁过期时间固定	业务未完成锁已丢	用 Redisson 自动续期
主从架构丢锁	主节点宕机，从节点未同步锁 → 多个客户端同时持锁	使用RedLock（争议大）或ZooKeeper / ETCD

⚠️关于 RedLock：
Redis 作者提出的一种多节点容错方案，但 Martin Kleppmann 等专家指出其在时钟漂移场景下仍不安全。一般业务建议用 Redisson + 单 Redis 实例（高可用由哨兵/Cluster 保证）即可。

---

七、总结：分布式锁最佳实践

1. 永远不要用SETNX + EXPIRE分开写！
2. 解锁必须用 Lua 脚本校验持有者 ID！
3. 业务时间不确定？上 Redisson！
4. 高可用靠 Redis 哨兵/Cluster，而非 RedLock！
5. 锁的粒度尽量小，减少持有时间！

---

结语

分布式锁看似简单，实则暗流涌动。一个没有自动续期、没有持有者校验的锁，等于没有锁！

在生产环境中，强烈建议直接使用 Redisson，它已经帮你踩平了所有坑。自己造轮子？除非你愿意承担资损风险！

视频看了几百小时还迷糊？关注我，几分钟让你秒懂！