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

Spring Boot 中 Redis 分布式锁的正确使用姿势，我后悔没早知道

news 2026/5/11 12:51:54

Spring Boot 中 Redis 分布式锁的正确使用姿势，我后悔没早知道

上个月项目里一个定时任务重复执行了两次，导致数据被重复处理，查了很久才发现是分布式锁失效了。当时我用的是 Redis SETNX 命令，自认为写得没问题，结果在并发场景下完全不行。这篇文章把踩过的坑和正确的做法分享出来，希望你们别再重蹈覆辙。

一、为什么你的分布式锁总失效？

先说说我踩的第一个坑。当时我自信满满地写了这样的代码：

publicBooleantryLock(StringlockKey,StringrequestId){Booleanresult=redisTemplate.opsForValue().setIfAbsent(lockKey,requestId,10,TimeUnit.SECONDS);returnresult;}

看起来挺完美对吧？设置了 10 秒过期时间，防止锁死。但是问题来了：

问题场景：线程 A 获取锁后开始执行任务，执行到一半时业务逻辑耗时超过了 10 秒，锁自动过期释放。此时线程 B 正好进来，也成功获取了锁。这样 A 和 B 同时在执行同一任务，数据就被重复处理了。

根本原因：我没有正确理解 Redis 分布式锁的"看门狗"机制。锁的过期时间应该由业务执行时间动态决定，而不是写死一个固定值。

二、Redis 分布式锁的核心原理

想用好分布式锁，先得搞懂它的核心原理。Redis 分布式锁本质上是利用 SETNX（SET if Not eXists）命令的原子性：

// 伪代码：获取锁if(redis.setnx(lockKey,requestId)==1){// 获取成功，设置过期时间redis.expire(lockKey,30);try{// 业务逻辑}finally{// 释放锁if(requestId.equals(redis.get(lockKey))){redis.del(lockKey);}}}

但这段代码有三个致命问题：

问题1：SETNX 和 EXPIRE 不是原子操作
如果程序在 SETNX 成功后、EXPIRE 执行前崩溃，锁就永远不会过期。

问题2：释放锁时没有验证价值
如果线程 A 的锁过期了，线程 B 获取了新锁，此时线程 A 执行完毕去释放锁，会把线程 B 的锁给释放掉。

问题3：无法自动续期
业务执行时间超过锁过期时间，锁自动失效，其他线程可以进来搞破坏。

三、Redisson 框架的正确打开方式

说了这么多坑，该上正确的解决方案了。Redisson 是 Java 中最成熟的 Redis 客户端之一，它帮我们封装好了分布式锁的所有细节。

1. 引入依赖

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

2. 配置 Redisson 客户端

@ConfigurationpublicclassRedissonConfig{@Value("${spring.data.redis.host}")privateStringhost;@Value("${spring.data.redis.port}")privateStringport;@BeanpublicRedissonClientredissonClient(){Configconfig=newConfig();Stringaddress="redis://"+host+":"+port;config.useSingleServer().setAddress(address).setPassword("yourpassword")// 如果有密码.setConnectionPoolSize(64).setConnectionMinimumIdleSize(10);returnRedisson.create(config);}}

3. 使用分布式锁

@ServicepublicclassOrderService{@AutowiredprivateRedissonClientredissonClient;publicvoidcreateOrder(Orderorder){StringlockKey="order:lock:"+order.getProductId();RLocklock=redissonClient.getLock(lockKey);try{// 等待锁超时时间 10 秒，自动解锁时间 30 秒// watchDog 会自动续期lock.lock(30,TimeUnit.SECONDS);// 业务逻辑：检查库存、创建订单、扣减库存checkStock(order);saveOrder(order);deductStock(order);}catch(Exceptione){log.error("Order creation failed",e);thrownewRuntimeException("创建订单失败",e);}finally{// 释放锁if(lock.isHeldByCurrentThread()){lock.unlock();}}}}

这样写有几个好处：

自动续期：Redisson 内置看门狗机制，默认每 10 秒检查一次，如果业务还在执行，自动续期 30 秒
原子操作：获取锁和设置过期时间是原子执行的
可重入：同一个线程可以多次获取同一把锁

四、常见坑点与最佳实践

坑点1：锁的 key 设计不合理

错误做法：所有业务都用同一个 key"lock"

正确做法：按业务维度设计 key，例如：

// 订单业务StringlockKey="lock:order:"+orderId;// 库存业务StringlockKey="lock:stock:"+productId;// 分布式环境下，用 UUID + 线程 ID 确保唯一性StringrequestId=UUID.randomUUID().toString()+":"+Thread.currentThread().getId();

坑点2：释放锁时没有验证 owner

错误做法：

// 直接删除，不检查是谁的锁redisTemplate.delete(lockKey);

正确做法：

// Redisson 自动处理了这个逻辑// 释放锁时会验证是否是当前线程持有的锁lock.unlock();

如果用原生 Redis，要用 Lua 脚本保证原子性：

Stringscript="if redis.call('get', KEYS[1]) == ARGV[1] then "+"return redis.call('del', KEYS[1]) else return 0 end";redisTemplate.execute(newDefaultRedisScript<>(script,Long.class),Collections.singletonList(lockKey),requestId);

坑点3：没有处理获取锁失败的情况

错误做法：获取不到锁就直接报错

正确做法：根据业务场景选择等待策略

// 策略1：等待并重试booleanacquired=lock.tryLock(10,30,TimeUnit.SECONDS);if(acquired){try{// 业务逻辑}finally{lock.unlock();}}else{// 获取锁失败，执行降级逻辑log.warn("Failed to acquire lock, executing fallback");executeFallback();}// 策略2：立即返回，不阻塞if(lock.tryLock()){try{// 业务逻辑}finally{lock.unlock();}}else{// 直接返回结果或提示用户returnResult.fail("系统繁忙，请稍后重试");}

坑点4：集群环境下锁失效

如果 Redis 是主从架构，主节点宕机时可能导致锁丢失。建议使用 RedLock 算法或 Redis Cluster：

// Redisson RedLock 配置RLocklock1=redissonClient1.getLock(lockKey);RLocklock2=redissonClient2.getLock(lockKey);RLocklock3=redissonClient3.getLock(lockKey);RedissonRedLockredLock=newRedissonRedLock(lock1,lock2,lock3);redLock.lock();try{// 业务逻辑}finally{redLock.unlock();}