一、业务背景
有些业务请求,属于耗时操作,需要加锁,防止后续的并发操作,同时对数据库的数据进行操作,需要避免对之前的业务造成影响。
二、分析流程
使用 Redis
作为分布式锁,将锁的状态放到 Redis
统一维护,解决集群中单机 JVM
信息不互通的问题,规定操作顺序,保护用户的数据正确。
梳理设计流程
-
新建注解 @interface,在注解里设定入参标志
-
增加 AOP 切点,扫描特定注解
-
建立 @Aspect 切面任务,注册 bean 和拦截特定方法
-
特定方法参数 ProceedingJoinPoint,对方法 pjp.proceed() 前后进行拦截
-
切点前进行加锁,任务执行后进行删除 key
核心步骤:加锁、解锁和续时
加锁
使用了 RedisTemplate 的 opsForValue.setIfAbsent 方法,判断是否有 key,设定一个随机数 UUID.random().toString,生成一个随机数作为 value。
从 redis 中获取锁之后,对 key 设定 expire 失效时间,到期后自动释放锁。
按照这种设计,只有第一个成功设定 Key
的请求,才能进行后续的数据操作,后续其它请求由于无法获得:closed_lock_with_key:资源,将会失败结束。
超时问题
担心 pjp.proceed()
切点执行的方法太耗时,导致 Redis
中的 key
由于超时提前释放了。
例如,线程 A 先获取锁,proceed 方法耗时,超过了锁超时时间,到期释放了锁,这时另一个线程 B 成功获取 Redis
锁,两个线程同时对同一批数据进行操作,导致数据不准确。
解决方案:增加一个「续时」
任务不完成,锁不释放:
维护了一个定时线程池 ScheduledExecutorService
,每隔 2s 去扫描加入队列中的 Task,判断是否失效时间是否快到了,公式为:【失效时间】<= 【当前时间】+【失效间隔(三分之一超时)】
/**
* 线程池,每个 JVM 使用一个线程去维护 keyAliveTime,定时执行 runnable
*/
private static final ScheduledExecutorService SCHEDULER =
new ScheduledThreadPoolExecutor(1,
new BasicThreadFactory.Builder().namingPattern("redisLock-schedule-pool").daemon(true).build());
static {
SCHEDULER.scheduleAtFixedRate(() -> {
// do something to extend time
}, 0, 2, TimeUnit.SECONDS);
}
三、设计方案
经过上面的分析,同事小:fish:设计出了这个方案:
前面已经说了整体流程,这里强调一下几个核心步骤:
-
拦截注解 @RedisLock,获取必要的参数