使用注解实现redis分布式锁毕设方案

1.业务背景

2.分析流程

加锁

超时问题

解决方案:增加一个续时

3.设计方案

4.实操

相关属性类配置

核心切面拦截的操作

5.开始测试

6.总结

1.业务背景

在系统的开发过程中，我们发现有些业务请求是耗时的操作，需要对数据库进行操作，因此需要进行加锁操作，以防止后续的并发操作对之前的业务造成影响。同时，我们还实现了基于 Spring Boot + MyBatis Plus + Vue & Element 的后台管理系统和用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能。我们相信这些功能的实现将使系统更加完善，用户的体验也会得到极大的提升。

2.分析流程

在这个分析流程中，我们使用 Redis 作为分布式锁，将锁的状态放到 Redis 中进行统一维护。这样做的好处是，可以解决集群中单机 JVM 信息不互通的问题，规定操作顺序，保护用户的数据正确。下面我们来详细地介绍一下设计流程：

首先，我们需要新建一个注解 @interface，并在注解中设定入参标志，这样可以方便我们在后面的步骤中使用。

接下来，我们需要增加一个 AOP 切点，用于扫描特定注解。

然后，我们需要建立一个 @Aspect 切面任务，用于注册 bean 和拦截特定方法。

特定方法参数 ProceedingJoinPoint，对方法 pjp.proceed() 前后进行拦截。

切点前进行加锁，任务执行后进行删除 key。

除了上述步骤之外，我们还需要进行一些核心步骤，包括加锁、解锁和续时。这些步骤非常重要，可以确保我们的分析流程更加完善和准确。

加锁

在本文中，介绍了使用 RedisTemplate 的 opsForValue.setIfAbsent 方法实现分布式锁，防止多个线程同时访问相同的资源。具体实现方式是：在 Redis 中设定一个随机数 UUID.random().toString，作为 value，并使用 opsForValue.setIfAbsent 方法设定该 key 的值，判断是否有 key。只有第一个成功设定 key 的请求，才能进行后续的数据操作，后续其它请求由于无法获得锁资源，将会失败结束。另外，从 redis 中获取锁之后，对 key 设定 expire 失效时间，到期后自动释放锁。

超时问题

然而，本文也提到了一些在实际应用中可能会遇到的问题。一个主要问题是任务执行时间过长，导致锁的过期时间到期，锁被自动释放，但任务还没有完成。这种情况下，另一个线程可能会获取到相同的锁，进而对相同的资源进行操作，导致数据出现不准确的情况。

解决方案:增加一个续时

为了解决上述问题，本文提出了一种解决方案：增加一个「续时」。具体来说，可以使用定时线程池 ScheduledExecutorService，每隔 2s 去扫描加入队列中的 Task，判断是否失效时间是否快到了。如果失效时间快到了，就将失效时间延长三分之一的过期时间。这样可以确保任务得到充分的执行时间，同时又不会出现多个线程同时访问相同资源的情况。

​

3.设计方案

经过上面的分析，设计出了这个方案：

​

前面提到了整体流程，接下来我们将详细介绍一下核心步骤:

首先，我们需要对 @RedisLock 注解进行拦截。在此过程中，我们需要确保获取必要的参数，以便后续的操作。

接下来，我们需要进行加锁操作。在这个步骤中，我们会使用 Redis 数据库来实现分布式锁。通过这种方式，我们可以确保同一时间只有一个线程可以访问特定的资源。

在加锁之后，我们需要进行续时操作。这是一项非常重要的步骤，因为它可以确保锁在业务处理期间不会过期。如果锁在处理期间过期，那么其他线程就有机会访问同一个资源，这可能导致数据不一致的问题。

最后，在结束业务处理之后，我们需要释放锁。这是一个非常关键的步骤，因为如果我们不释放锁，那么其他线程就无法访问同一个资源。因此，我们必须确保在业务处理完成后及时释放锁，以便其他线程可以访问该资源。

4.实操

之前也有整理过 AOP 使用方法，可以参考一下

相关属性类配置

核心切面拦截的操作

1. 任务队列保留参数

​

设定被拦截的名字

 ​

RedisLockAspect.java 该类分成三部分来描述具体作用

​

前面步骤定义了我们想要拦截的切点，下一步就是在切点前后做一些自定义操作：

​

上述流程简单总结一下：

解析注解参数，获取注解值和方法上的参数值

redis 加锁并且设置超时时间

将本次 Task 信息加入「延时」队列中，进行续时，方式提前释放锁

加了一个线程中断标志

结束请求，finally 中释放锁

这个续时操作的目的是在任务队列中对超时的任务进行处理。在这种情况下，我们使用了 ScheduledExecutorService 来维护一个线程，该线程不断对任务队列中的任务进行判断，并延长超时时间。这样，即使任务队列中的任务超过了预定时间，我们也可以确保任务能够在规定的时间内完成，从而使系统更加稳定可靠:

​

这段代码的目的是为了实现设计图中虚线框的思想。在这段代码中，我们引入了「线程中断」Thread#interrupt，以防止请求十分耗时，导致提前释放了锁。这个操作可以在超过重试次数后，让线程中断。需要注意的是，这个操作未经过严谨测试，仅供参考。

虽然这个方法可以解决一时的问题，但我们还是建议从根源上查找问题，分析耗时路径，并进行业务优化或其它处理，避免这些耗时操作。这样可以避免在未来出现类似的问题。

因此，我们建议在代码中加入更多的Log。这样在分析问题时，可以更快速地找到答案，减少问题的解决时间。

5.开始测试

在一个入口方法中，使用该注解，然后在业务中模拟耗时请求，使用了 Thread#sleep

​

使用时，可以在方法上添加该注解，然后根据需要设定相应参数。该注解可以区分多种业务类型，从而限制该业务被同时操作，提高了系统的并发性能和安全性。

同时，该注解还可以帮助开发人员更好地维护系统的稳定性和可靠性。例如，当系统面临高并发请求时，该注解可以有效地控制请求的访问频率，避免系统的崩溃和数据的丢失。

测试结果如下：

​

我这里测试的是重试次数过多，失败的场景，如果减少睡眠时间，就能让业务正常执行。

如果同时请求，你将会发现以下错误信息：

​

6.总结

在处理耗时业务和核心数据时，需要避免重复请求同时操作数据，以防止数据不正确。因此，我们可以使用分布式锁来保护它们。

设计流程如下：

新建注解 @interface，在注解里设定入参标志

增加 AOP 切点，扫描特定注解

建立 @Aspect 切面任务，注册 bean 和拦截特定方法

使用特定方法参数 ProceedingJoinPoint，对方法 pjp.proceed() 前后进行拦截

切点前进行加锁，任务执行后进行删除 key

通过学习小伙伴的代码设计，我们了解了分布式锁的具体实现。仿照他的设计，我们重新写了一份简化版的业务处理，并考虑了之前没有考虑到的「续时」操作。为了避免锁提前释放，我们使用了守护线程来定时判断和延长超时时间。

因此，本次学习回顾了以下三个知识点：

AOP 的实现和常用方法

定时线程池 ScheduledExecutorService 的使用和参数含义

线程 Thread#interrupt 的含义以及用法。这个知识点挺有意思的，可以深入再学习一下。