0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

Spring Boot實(shí)現(xiàn)Redis分布式鎖

我快閉嘴 ? 來源:芋道源碼 ? 作者:芋道源碼 ? 2022-10-09 11:55 ? 次閱讀

一、業(yè)務(wù)背景

有些業(yè)務(wù)請求,屬于耗時操作,需要加鎖,防止后續(xù)的并發(fā)操作,同時對數(shù)據(jù)庫的數(shù)據(jù)進(jìn)行操作,需要避免對之前的業(yè)務(wù)造成影響。

基于 Spring Boot + MyBatis Plus + Vue & Element 實(shí)現(xiàn)的后臺管理系統(tǒng) + 用戶小程序,支持 RBAC 動態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

二、分析流程

使用 Redis 作為分布式鎖,將鎖的狀態(tài)放到 Redis 統(tǒng)一維護(hù),解決集群中單機(jī) JVM 信息不互通的問題,規(guī)定操作順序,保護(hù)用戶的數(shù)據(jù)正確。

梳理設(shè)計(jì)流程

新建注解 @interface,在注解里設(shè)定入?yún)?biāo)志

增加 AOP 切點(diǎn),掃描特定注解

建立 @Aspect 切面任務(wù),注冊 bean 和攔截特定方法

特定方法參數(shù) ProceedingJoinPoint,對方法 pjp.proceed() 前后進(jìn)行攔截

切點(diǎn)前進(jìn)行加鎖,任務(wù)執(zhí)行后進(jìn)行刪除 key

核心步驟:加鎖、解鎖和續(xù)時

加鎖

使用了 RedisTemplate 的 opsForValue.setIfAbsent 方法,判斷是否有 key,設(shè)定一個隨機(jī)數(shù) UUID.random().toString,生成一個隨機(jī)數(shù)作為 value。

從 redis 中獲取鎖之后,對 key 設(shè)定 expire 失效時間,到期后自動釋放鎖。

按照這種設(shè)計(jì),只有第一個成功設(shè)定 Key 的請求,才能進(jìn)行后續(xù)的數(shù)據(jù)操作,后續(xù)其它請求由于無法獲得資源,將會失敗結(jié)束。

超時問題

擔(dān)心 pjp.proceed() 切點(diǎn)執(zhí)行的方法太耗時,導(dǎo)致 Redis 中的 key 由于超時提前釋放了。

例如,線程 A 先獲取鎖,proceed 方法耗時,超過了鎖超時時間,到期釋放了鎖,這時另一個線程 B 成功獲取 Redis 鎖,兩個線程同時對同一批數(shù)據(jù)進(jìn)行操作,導(dǎo)致數(shù)據(jù)不準(zhǔn)確。

解決方案:增加一個「續(xù)時」

任務(wù)不完成,鎖不釋放:

維護(hù)了一個定時線程池 ScheduledExecutorService,每隔 2s 去掃描加入隊(duì)列中的 Task,判斷是否失效時間是否快到了,公式為:【失效時間】<= 【當(dāng)前時間】+【失效間隔(三分之一超時)】

/**
*線程池,每個JVM使用一個線程去維護(hù)keyAliveTime,定時執(zhí)行runnable
*/
privatestaticfinalScheduledExecutorServiceSCHEDULER=
newScheduledThreadPoolExecutor(1,
newBasicThreadFactory.Builder().namingPattern("redisLock-schedule-pool").daemon(true).build());
static{
SCHEDULER.scheduleAtFixedRate(()->{
//dosomethingtoextendtime
},0,2,TimeUnit.SECONDS);
}

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實(shí)現(xiàn)的后臺管理系統(tǒng) + 用戶小程序,支持 RBAC 動態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

三、設(shè)計(jì)方案

經(jīng)過上面的分析,同事小設(shè)計(jì)出了這個方案:

ea9c301a-4162-11ed-96c9-dac502259ad0.png

前面已經(jīng)說了整體流程,這里強(qiáng)調(diào)一下幾個核心步驟:

攔截注解 @RedisLock,獲取必要的參數(shù)

加鎖操作

續(xù)時操作

結(jié)束業(yè)務(wù),釋放鎖

四、實(shí)操

之前也有整理過 AOP 使用方法,可以參考一下

相關(guān)屬性類配置

業(yè)務(wù)屬性枚舉設(shè)定

publicenumRedisLockTypeEnum{
/**
*自定義key前綴
*/
ONE("Business1","Test1"),

TWO("Business2","Test2");
privateStringcode;
privateStringdesc;
RedisLockTypeEnum(Stringcode,Stringdesc){
this.code=code;
this.desc=desc;
}
publicStringgetCode(){
returncode;
}
publicStringgetDesc(){
returndesc;
}
publicStringgetUniqueKey(Stringkey){
returnString.format("%s:%s",this.getCode(),key);
}
}

任務(wù)隊(duì)列保存參數(shù)

publicclassRedisLockDefinitionHolder{
/**
*業(yè)務(wù)唯一key
*/
privateStringbusinessKey;
/**
*加鎖時間(秒s)
*/
privateLonglockTime;
/**
*上次更新時間(ms)
*/
privateLonglastModifyTime;
/**
*保存當(dāng)前線程
*/
privateThreadcurrentTread;
/**
*總共嘗試次數(shù)
*/
privateinttryCount;
/**
*當(dāng)前嘗試次數(shù)
*/
privateintcurrentCount;
/**
*更新的時間周期(毫秒),公式=加鎖時間(轉(zhuǎn)成毫秒)/3
*/
privateLongmodifyPeriod;
publicRedisLockDefinitionHolder(StringbusinessKey,LonglockTime,LonglastModifyTime,ThreadcurrentTread,inttryCount){
this.businessKey=businessKey;
this.lockTime=lockTime;
this.lastModifyTime=lastModifyTime;
this.currentTread=currentTread;
this.tryCount=tryCount;
this.modifyPeriod=lockTime*1000/3;
}
}

設(shè)定被攔截的注解名字

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD,ElementType.TYPE})
public@interfaceRedisLockAnnotation{
/**
*特定參數(shù)識別,默認(rèn)取第0個下標(biāo)
*/
intlockFiled()default0;
/**
*超時重試次數(shù)
*/
inttryCount()default3;
/**
*自定義加鎖類型
*/
RedisLockTypeEnumtypeEnum();
/**
*釋放時間,秒s單位
*/
longlockTime()default30;
}

核心切面攔截的操作

RedisLockAspect.java 該類分成三部分來描述具體作用

Pointcut 設(shè)定

/**
*@annotation中的路徑表示攔截特定注解
*/
@Pointcut("@annotation(cn.sevenyuan.demo.aop.lock.RedisLockAnnotation)")
publicvoidredisLockPC(){
}

Around 前后進(jìn)行加鎖和釋放鎖

前面步驟定義了我們想要攔截的切點(diǎn),下一步就是在切點(diǎn)前后做一些自定義操作:

@Around(value="redisLockPC()")
publicObjectaround(ProceedingJoinPointpjp)throwsThrowable{
//解析參數(shù)
Methodmethod=resolveMethod(pjp);
RedisLockAnnotationannotation=method.getAnnotation(RedisLockAnnotation.class);
RedisLockTypeEnumtypeEnum=annotation.typeEnum();
Object[]params=pjp.getArgs();
StringukString=params[annotation.lockFiled()].toString();
//省略很多參數(shù)校驗(yàn)和判空
StringbusinessKey=typeEnum.getUniqueKey(ukString);
StringuniqueValue=UUID.randomUUID().toString();
//加鎖
Objectresult=null;
try{
booleanisSuccess=redisTemplate.opsForValue().setIfAbsent(businessKey,uniqueValue);
if(!isSuccess){
thrownewException("Youcan'tdoit,becauseanotherhasgetthelock=-=");
}
redisTemplate.expire(businessKey,annotation.lockTime(),TimeUnit.SECONDS);
ThreadcurrentThread=Thread.currentThread();
//將本次Task信息加入「延時」隊(duì)列中
holderList.add(newRedisLockDefinitionHolder(businessKey,annotation.lockTime(),System.currentTimeMillis(),
currentThread,annotation.tryCount()));
//執(zhí)行業(yè)務(wù)操作
result=pjp.proceed();
//線程被中斷,拋出異常,中斷此次請求
if(currentThread.isInterrupted()){
thrownewInterruptedException("Youhadbeeninterrupted=-=");
}
}catch(InterruptedExceptione){
log.error("Interruptexception,rollbacktransaction",e);
thrownewException("Interruptexception,pleasesendrequestagain");
}catch(Exceptione){
log.error("hassomeerror,pleasecheckagain",e);
}finally{
//請求結(jié)束后,強(qiáng)制刪掉key,釋放鎖
redisTemplate.delete(businessKey);
log.info("releasethelock,businessKeyis["+businessKey+"]");
}
returnresult;
}

上述流程簡單總結(jié)一下:

解析注解參數(shù),獲取注解值和方法上的參數(shù)值

redis 加鎖并且設(shè)置超時時間

將本次 Task 信息加入「延時」隊(duì)列中,進(jìn)行續(xù)時,方式提前釋放鎖

加了一個線程中斷標(biāo)志

結(jié)束請求,finally 中釋放鎖

續(xù)時操作

這里用了 ScheduledExecutorService,維護(hù)了一個線程,不斷對任務(wù)隊(duì)列中的任務(wù)進(jìn)行判斷和延長超時時間:

//掃描的任務(wù)隊(duì)列
privatestaticConcurrentLinkedQueueholderList=newConcurrentLinkedQueue();
/**
*線程池,維護(hù)keyAliveTime
*/
privatestaticfinalScheduledExecutorServiceSCHEDULER=newScheduledThreadPoolExecutor(1,
newBasicThreadFactory.Builder().namingPattern("redisLock-schedule-pool").daemon(true).build());
{
//兩秒執(zhí)行一次「續(xù)時」操作
SCHEDULER.scheduleAtFixedRate(()->{
//這里記得加try-catch,否者報(bào)錯后定時任務(wù)將不會再執(zhí)行=-=
Iteratoriterator=holderList.iterator();
while(iterator.hasNext()){
RedisLockDefinitionHolderholder=iterator.next();
//判空
if(holder==null){
iterator.remove();
continue;
}
//判斷key是否還有效,無效的話進(jìn)行移除
if(redisTemplate.opsForValue().get(holder.getBusinessKey())==null){
iterator.remove();
continue;
}
//超時重試次數(shù),超過時給線程設(shè)定中斷
if(holder.getCurrentCount()>holder.getTryCount()){
holder.getCurrentTread().interrupt();
iterator.remove();
continue;
}
//判斷是否進(jìn)入最后三分之一時間
longcurTime=System.currentTimeMillis();
booleanshouldExtend=(holder.getLastModifyTime()+holder.getModifyPeriod())<=?curTime;
????????????if?(shouldExtend)?{
????????????????holder.setLastModifyTime(curTime);
????????????????redisTemplate.expire(holder.getBusinessKey(),?holder.getLockTime(),?TimeUnit.SECONDS);
????????????????log.info("businessKey?:?["?+?holder.getBusinessKey()?+?"],?try?count?:?"?+?holder.getCurrentCount());
????????????????holder.setCurrentCount(holder.getCurrentCount()?+?1);
????????????}
????????}
????},?0,?2,?TimeUnit.SECONDS);
}

這段代碼,用來實(shí)現(xiàn)設(shè)計(jì)圖中虛線框的思想,避免一個請求十分耗時,導(dǎo)致提前釋放了鎖。

這里加了「線程中斷」Thread#interrupt,希望超過重試次數(shù)后,能讓線程中斷 (未經(jīng)嚴(yán)謹(jǐn)測試,僅供參考哈哈哈哈)

不過建議如果遇到這么耗時的請求,還是能夠從根源上查找,分析耗時路徑,進(jìn)行業(yè)務(wù)優(yōu)化或其它處理,避免這些耗時操作。

所以記得多打點(diǎn) Log,分析問題時可以更快一點(diǎn)。

五、開始測試

在一個入口方法中,使用該注解,然后在業(yè)務(wù)中模擬耗時請求,使用了 Thread#sleep

@GetMapping("/testRedisLock")
@RedisLockAnnotation(typeEnum=RedisLockTypeEnum.ONE,lockTime=3)
publicBooktestRedisLock(@RequestParam("userId")LonguserId){
try{
log.info("睡眠執(zhí)行前");
Thread.sleep(10000);
log.info("睡眠執(zhí)行后");
}catch(Exceptione){
//logerror
log.info("hassomeerror",e);
}
returnnull;
}

使用時,在方法上添加該注解,然后設(shè)定相應(yīng)參數(shù)即可,根據(jù) typeEnum 可以區(qū)分多種業(yè)務(wù),限制該業(yè)務(wù)被同時操作。

測試結(jié)果:

2020-04-0414:55:50.864INFO9326---[nio-8081-exec-1]c.s.demo.controller.BookController:睡眠執(zhí)行前
2020-04-0414:55:52.855INFO9326---[k-schedule-pool]c.s.demo.aop.lock.RedisLockAspect:businessKey:[Business1:1024],trycount:0
2020-04-0414:55:54.851INFO9326---[k-schedule-pool]c.s.demo.aop.lock.RedisLockAspect:businessKey:[Business1:1024],trycount:1
2020-04-0414:55:56.851INFO9326---[k-schedule-pool]c.s.demo.aop.lock.RedisLockAspect:businessKey:[Business1:1024],trycount:2
2020-04-0414:55:58.852INFO9326---[k-schedule-pool]c.s.demo.aop.lock.RedisLockAspect:businessKey:[Business1:1024],trycount:3
2020-04-0414:56:00.857INFO9326---[nio-8081-exec-1]c.s.demo.controller.BookController:hassomeerror
java.lang.InterruptedException:sleepinterrupted
atjava.lang.Thread.sleep(NativeMethod)[na:1.8.0_221]

我這里測試的是重試次數(shù)過多,失敗的場景,如果減少睡眠時間,就能讓業(yè)務(wù)正常執(zhí)行。

如果同時請求,你將會發(fā)現(xiàn)以下錯誤信息:

eab63cc6-4162-11ed-96c9-dac502259ad0.png

表示我們的鎖的確生效了,避免了重復(fù)請求。

六、總結(jié)

對于耗時業(yè)務(wù)和核心數(shù)據(jù),不能讓重復(fù)的請求同時操作數(shù)據(jù),避免數(shù)據(jù)的不正確,所以要使用分布式鎖來對它們進(jìn)行保護(hù)。

再來梳理一下設(shè)計(jì)流程:

新建注解 @interface,在注解里設(shè)定入?yún)?biāo)志

增加 AOP 切點(diǎn),掃描特定注解

建立 @Aspect 切面任務(wù),注冊 bean 和攔截特定方法

特定方法參數(shù) ProceedingJoinPoint,對方法 pjp.proceed() 前后進(jìn)行攔截

切點(diǎn)前進(jìn)行加鎖,任務(wù)執(zhí)行后進(jìn)行刪除 key

本次學(xué)習(xí)是通過 Review 小伙伴的代碼設(shè)計(jì),從中了解分布式鎖的具體實(shí)現(xiàn),仿照他的設(shè)計(jì),重新寫了一份簡化版的業(yè)務(wù)處理。對于之前沒考慮到的「續(xù)時」操作,這里使用了守護(hù)線程來定時判斷和延長超時時間,避免了鎖提前釋放。

于是乎,同時回顧了三個知識點(diǎn):

1、AOP 的實(shí)現(xiàn)和常用方法

2、定時線程池 ScheduledExecutorService 的使用和參數(shù)含義

3、線程 Thread#interrupt 的含義以及用法(這個挺有意思的,可以深入再學(xué)習(xí)一下)

審核編輯:湯梓紅
聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報(bào)投訴
  • spring
    +關(guān)注

    關(guān)注

    0

    文章

    338

    瀏覽量

    14296
  • Redis
    +關(guān)注

    關(guān)注

    0

    文章

    370

    瀏覽量

    10830

原文標(biāo)題:Spring Boot加一個注解,輕松實(shí)現(xiàn) Redis 分布式鎖

文章出處:【微信號:芋道源碼,微信公眾號:芋道源碼】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

收藏 人收藏

    評論

    相關(guān)推薦

    redis分布式場景實(shí)現(xiàn)

    今天帶大家深入剖析一下Redis分布式,徹底搞懂它。 場景 既然要搞懂Redis分布式,那肯
    的頭像 發(fā)表于 09-25 17:09 ?684次閱讀

    在 Java 中利用 redis 實(shí)現(xiàn)一個分布式服務(wù)

    在 Java 中利用 redis 實(shí)現(xiàn)一個分布式服務(wù)
    發(fā)表于 07-05 13:14

    Redis 分布式的正確實(shí)現(xiàn)方式

    分布式一般有三種實(shí)現(xiàn)方式:1. 數(shù)據(jù)庫樂觀;2. 基于Redis分布式
    的頭像 發(fā)表于 05-31 14:19 ?3559次閱讀

    Redis分布式真的安全嗎?

    今天我們來聊一聊Redis分布式。
    的頭像 發(fā)表于 11-02 14:07 ?971次閱讀

    如何使用注解實(shí)現(xiàn)redis分布式!

    使用 Redis 作為分布式,將的狀態(tài)放到 Redis 統(tǒng)一維護(hù),解決集群中單機(jī) JVM 信息不互通的問題,規(guī)定操作順序,保護(hù)用戶的數(shù)據(jù)
    發(fā)表于 04-25 12:42 ?625次閱讀
    如何使用注解<b class='flag-5'>實(shí)現(xiàn)</b><b class='flag-5'>redis</b><b class='flag-5'>分布式</b><b class='flag-5'>鎖</b>!

    深入理解redis分布式

    深入理解redis分布式 哈嘍,大家好,我是指北君。 本篇文件我們來介紹如何Redis實(shí)現(xiàn)分布式
    的頭像 發(fā)表于 10-08 14:13 ?888次閱讀
    深入理解<b class='flag-5'>redis</b><b class='flag-5'>分布式</b><b class='flag-5'>鎖</b>

    redis分布式如何實(shí)現(xiàn)

    Redis分布式是一種基于Redis實(shí)現(xiàn)的機(jī)制,可以用于多個進(jìn)程或多臺服務(wù)器之間對共享資源的并發(fā)訪問控制。在
    的頭像 發(fā)表于 11-16 11:29 ?490次閱讀

    redis分布式可能出現(xiàn)的問題

    Redis分布式是一種常用的機(jī)制,用于解決多個進(jìn)程或多臺服務(wù)器對共享資源的并發(fā)訪問問題。然而,由于分布式環(huán)境的復(fù)雜性,使用
    的頭像 發(fā)表于 11-16 11:40 ?1332次閱讀

    redis分布式死鎖處理方案

    引言: 隨著分布式系統(tǒng)的廣泛應(yīng)用,尤其是在大規(guī)模并發(fā)操作下,對并發(fā)控制的需求越來越高。Redis分布式作為一種常見的分布式
    的頭像 發(fā)表于 11-16 11:44 ?1664次閱讀

    redis分布式的應(yīng)用場景有哪些

    Redis分布式是一種基于Redis實(shí)現(xiàn)分布式
    的頭像 發(fā)表于 12-04 11:21 ?1357次閱讀

    redis分布式三個方法

    Redis是一種高性能的分布式緩存和鍵值存儲系統(tǒng),它提供了一種可靠的分布式解決方案。在分布式系統(tǒng)中,由于多個節(jié)點(diǎn)之間的并發(fā)訪問,需要使用
    的頭像 發(fā)表于 12-04 11:22 ?1378次閱讀

    如何實(shí)現(xiàn)Redis分布式

    機(jī)制,下面將詳細(xì)介紹如何實(shí)現(xiàn)Redis分布式。 一、引言 在分布式系統(tǒng)中,多個節(jié)點(diǎn)可能同時讀寫同一共享資源。如果沒有
    的頭像 發(fā)表于 12-04 11:24 ?635次閱讀

    redis分布式可能出現(xiàn)的問題及解決方案

    Redis分布式是一種常見的解決分布式系統(tǒng)中并發(fā)問題的方案。雖然Redis分布式鎖具有許多優(yōu)點(diǎn)
    的頭像 發(fā)表于 12-04 11:29 ?890次閱讀

    淺析Redis 分布式解決方案

    Redis 分布式解決方案是一種基于Redis實(shí)現(xiàn)分布式
    的頭像 發(fā)表于 12-04 14:00 ?452次閱讀

    redis分布式的缺點(diǎn)

    Redis分布式是一種常見的用于解決分布式系統(tǒng)中資源爭用問題的解決方案。盡管Redis分布式
    的頭像 發(fā)表于 12-04 14:05 ?1169次閱讀