Redis 分布式锁过期了，还没处理完怎么办？

为了防止死锁，我们会给分布式锁加一个过期时间，但是万一这个时间到了，我们业务逻辑还没处理完，怎么办？

这是一个分布式应用里很常见到的需求，关于这个问题，有经验的程序员会怎么处理呢，今天的文章，V 哥来详细说一说，把这个问题彻底讲清楚。开干！

首先，我们在设置过期时间时要结合业务场景去考虑，尽量设置一个比较合理的值，就是理论上正常处理的话，在这个过期时间内是一定能处理完毕的。

之后，我们再来考虑对这个问题进行兜底设计。

关于这个问题，目前常见的解决方法有两种：

1. 守护线程“续命”：额外起一个线程，定期检查线程是否还持有锁，如果有则延长过期时间。Redisson 里面就实现了这个方案，使用“看门狗”定期检查（每1/3的锁时间检查1次），如果线程还持有锁，则刷新过期时间。

2. 超时回滚：当我们解锁时发现锁已经被其他线程获取了，说明此时我们执行的操作已经是“不安全”的了，此时需要进行回滚，并返回失败。

同时，需要进行告警，人为介入验证数据的正确性，然后找出超时原因，是否需要对超时时间进行优化等等。下面V哥分别用案例来介绍以上两种解决方法。对于进一步理解比较有帮助，请继续往下看。

守护线程“续命”

Redisson 是一个基于 Java 的 Redis 客户端库，它提供了多种分布式数据结构和服务，包括实现为 Redisson 对象的分布式锁。使用 Redisson 可以简化分布式锁的实现和管理，特别是它的自动续期功能，可以避免锁在业务执行期间过期。

以下是使用 Redisson 库实现自动续期的 Java 案例代码，以及详细流程步骤的解释：

1. 添加 Redisson 依赖

首先，需要在项目的 pom.xml 文件中添加 Redisson 的依赖：

<dependencies><!-- 其他依赖... --><dependency><groupId>org.redisson</groupId><artifactId>redisson-spring-boot-starter</artifactId><version>3.15.3</version> <!-- 请使用最新版本 --></dependency>
</dependencies>

2. 配置 Redisson

在 Spring Boot 应用中，可以通过配置类来配置 Redisson：

@Configuration
public class RedissonConfig {@Value("${spring.redis.host}")private String host;@Value("${spring.redis.port}")private int port;@Beanpublic Config redissonConfig() {Config config = new Config();SingleServerConfig singleServerConfig = config.useSingleServer();singleServerConfig.setAddress(String.format("%s:%d", host, port));singleServerConfig.setPassword("your-password"); // 如果需要密码return config;}
}

3. 使用 RedissonLock

在业务代码中，通过注入 RLock 来使用分布式锁：

@Service
public class SomeService {private final RLock lock;public SomeService(RLock lock) {this.lock = lock;}public void someMethod() {lock.lock(); // 加锁try {// 执行业务逻辑// ...} finally {lock.unlock(); // 释放锁}}
}

4. 自动续期机制

Redisson 的 RLock 对象会自动处理锁的续期。当一个线程获取了锁，Redisson 会在后台启动一个定时任务（看门狗），用于在锁即将过期时自动续期。
详细流程步骤：

• 获取锁：当调用 lock.lock() 时，Redisson 会尝试在 Redis 中创建一个具有过期时间的锁。

• 锁的自动续期：Redisson 会启动一个后台线程（看门狗），它会在锁的过期时间的一半时检查锁是否仍然被当前线程持有。

• 续期锁：如果锁仍然被持有，看门狗会延长锁的过期时间。这确保了即使业务逻辑执行时间较长，锁也不会过期。

• 执行业务逻辑：在锁的保护下，执行业务逻辑。

• 释放锁：当业务逻辑执行完毕后，调用 lock.unlock() 释放锁。如果当前线程是最后一个持有锁的线程，Redisson 会从 Redis 中删除锁。

• 异常处理：如果在执行业务逻辑时发生异常，finally 块中的 unlock() 调用确保了锁能够被释放，防止死锁。

• 看门狗线程终止：一旦锁被释放，看门狗线程会停止续期操作，并结束。

通过这种方式，Redisson 提供了一个简单而强大的机制来处理分布式锁的自动续期，从而减少了锁过期导致的问题。

超时回滚

使用超时回滚机制处理 Redis 分布式锁过期的情况，是指当一个线程因为执行时间过长导致持有的分布式锁过期，而其他线程又获取了同一把锁时，原线程需要能够检测到这一情况并执行业务逻辑的回滚操作。以下是使用 Java 实现的一个业务场景案例，以及详细流程步骤的解释：

1. 业务场景设定

假设我们有一个电商网站，需要处理订单支付的业务。为了保证在支付过程中数据的一致性，我们需要使用分布式锁来避免并发问题。

2. 定义分布式锁

我们首先定义一个分布式锁的接口 DistributedLock，然后实现这个接口：

public interface DistributedLock {boolean tryLock(String key, String requestId, long timeout, TimeUnit unit);boolean releaseLock(String key, String requestId);
}public class RedisDistributedLock implements DistributedLock {private final RedisTemplate<String, String> redisTemplate;private static final String LOCK_SCRIPT ="if redis.call('get', KEYS[1]) == ARGV[1] then " +"return redis.call('del', KEYS[1]) " +"else " +"return 0 " +"end";public RedisDistributedLock(RedisTemplate<String, String> redisTemplate) {this.redisTemplate = redisTemplate;}@Overridepublic boolean tryLock(String key, String requestId, long timeout, TimeUnit unit) {long expireTime = unit.toMillis(timeout);// 使用 Lua 脚本来确保原子性return redisTemplate.execute(new StringRedisSerializer(), new StringRedisSerializer(),new DefaultRedisScript<>(LOCK_SCRIPT, Boolean.class),Arrays.asList(key), requestId);}// 省略 releaseLock 方法的实现...
}

3. 业务逻辑实现

接下来，我们实现订单支付的业务逻辑：

@Service
public class OrderService {private final DistributedLock distributedLock;private final OrderRepository orderRepository;public OrderService(DistributedLock distributedLock, OrderRepository orderRepository) {this.distributedLock = distributedLock;this.orderRepository = orderRepository;}public void processPayment(String orderId) {String lockKey = "order:" + orderId;String requestId = UUID.randomUUID().toString();boolean isLocked = distributedLock.tryLock(lockKey, requestId, 30, TimeUnit.SECONDS);if (!isLocked) {throw new RuntimeException("Could not acquire lock for order: " + orderId);}try {// 执行支付逻辑Order order = orderRepository.findById(orderId).orElseThrow(() -> new RuntimeException("Order not found"));if (order.getStatus() == OrderStatus.PENDING) {// 执行扣款等操作...order.setStatus(OrderStatus.COMPLETED);orderRepository.save(order);}} catch (Exception e) {// 回滚逻辑// 根据业务需求进行回滚，例如恢复库存、撤销交易等throw e;} finally {// 释放锁distributedLock.releaseLock(lockKey, requestId);}}
}

4. 超时回滚流程步骤：

• 尝试获取锁：在执行业务逻辑之前，首先尝试获取分布式锁。

• 执行业务逻辑：如果成功获取锁，则执行支付逻辑，包括检查订单状态、扣款、更新订单状态等。

• 异常处理：如果在执行过程中发生异常，执行回滚逻辑，撤销已经进行的操作，以保证数据的一致性。

• 释放锁：无论业务逻辑是否成功执行，都需要在 finally 块中释放锁，以避免死锁。

• 超时回滚检测：如果业务逻辑执行时间过长导致锁过期，其他线程可能会获取到同一把锁并执行业务逻辑。在这种情况下，原线程在执行回滚逻辑时需要检测锁的状态，如果发现锁已经被其他线程持有，则需要根据业务需求进行相应的处理。

• 锁释放后的处理：在释放锁之后，如果业务逻辑执行失败，可能需要通知用户或者记录日志，以便进一步处理。

通过这种方式，我们可以确保即使在分布式锁过期的情况下，业务逻辑也能够通过超时回滚机制来保证数据的一致性和完整性。

搞定。关注“威哥爱编程”，一起消灭项目中一个一个问题，成长路上，我们搀扶前行。