redis分布式锁过期时间到了，但业务没执行完怎么办？

最新推荐文章于 2025-06-09 00:32:08 发布

置顶

zhao-33

最新推荐文章于 2025-06-09 00:32:08 发布

阅读量1w

点赞数 2

CC 4.0 BY-SA版权

分类专栏： Redis 文章标签： JAVA Redis分布式锁如何续期? 优化redisson对锁过期的处理 redis分布式锁

本文链接：https://blog.youkuaiyun.com/weixin_40098891/article/details/102771805

本文探讨了Redis分布式锁在过期时间到达时，如果业务未完成的处理方案。对比了Redisson的定时续约机制及其可能的资源浪费，提出了一个借鉴自旋锁优化思想的策略，即根据历史耗时动态调整锁的过期时间，以此减少不必要的续约操作。然而，该方法可能存在业务执行耗时差异较大导致效果不理想的缺点。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

redisson是如何处理的？

redisson给的答案是锁获取成功后，注册一个定时任务，每隔一定时间(this.internalLockLeaseTime / 3L)就去续约。internalLockLeaseTime可配置，默认30s。这种方式每次获取一个锁，就会创建一个定时任务，有些浪费。

我的处理

这里给出了一种方式，借鉴jvm对自旋锁优化的思想（根据历史耗时动态调整锁的过期时间），将续约的key的耗时保存在redis，再次获取锁时，直接使用上次耗时 + 10s 作为锁的过期时间，不用每次都去续约。缺点：获取锁后->释放锁前，若每次执行耗时差距过大（业务方法的各条流程耗时差距过大），将得不到预期的效果。

pom.xml如下：

<dependencies> 
   <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter</artifactId>
   </dependency>
   <dependency>
      <groupId>org.projectlombok</groupId>
      <artifactId>lombok</artifactId>
      <optional>true</optional>
   </dependency>
   <dependency>
      <groupId>org.springframework.data</groupId>
      <artifactId>spring-data-redis</artifactId>
      <version>2.1.10.RELEASE</version>
   </dependency>
   <dependency>
      <groupId>io.lettuce</groupId>
      <artifactId>lettuce-core</artifactId>
      <version>5.1.8.RELEASE</version>
   </dependency>
<dependencies>

代码如下：

package com.example.core;

import lombok.Data;
import lombok.ToString;
import lombok.extern.slf4j.Slf4j;
import org.springframework.data.redis.core.RedisCallback;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.data.redis.core.script.RedisScript;
import org.springframework.stereotype.Service;

import java.io.Serializable;
import java.util.*;
import java.util.concurrent.*;

/**
 * redis分布式锁
 * redis分布式锁过期时间到了，但业务还没执行完，怎么办？
 *    redisson给的答案是锁获取成功后，注册一个定时任务，每隔一定时间(this.internalLockLeaseTime / 3L)就去续约。
 *    internalLockLeaseTime可配置，默认30s。
 *    这种方式每次获取一个锁，就会创建一个定时任务，有些浪费
 * 这里借鉴jvm对自旋锁优化的思想，将续约的key的耗时保存在redis，再次获取锁时，直接使用上次耗时 + 10s 作为锁的过期时间，
 * 不用每次都去续约。
 * 缺点：获取锁后->释放锁前，若每次执行耗时差距过大（业务方法的各条流程耗时差距过大），将得不到预期的效果
 *
 */
@Slf4j
@Service
public class RedisDistributionLockPlus {

    /**
     * 加锁超时时间，单位毫秒， 即：加锁时间内执行完操作，如果未完成会有并发现象
     */
    private static final long DEFAULT_LOCK_TIMEOUT = 30;

    private static final long TIME_SECONDS_FIVE = 5 ;

    /**
     * 每个key的过期时间 {@link LockContent}
     */
    private Map<String, LockContent> lockContentMap = new ConcurrentHashMap<>(512);

    /**
     * redis执行成功的返回
     */
    private static final Long EXEC_SUCCESS = 1L;

    /**
     * 获取锁lua脚本， k1：获锁key, k2：续约耗时key, arg1:requestId，arg2：超时时间
     */
    private static final String