溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

redis的分布式鎖組件,簡單方便快捷接入使項目擁有分布式鎖

發(fā)布時間:2020-06-06 13:04:36 來源:網(wǎng)絡 閱讀:563 作者:wx5d6cccb1cb158 欄目:建站服務器

spring-boot-klock-starter

基于redis的分布式鎖spring-boot starter組件,使得項目擁有分布式鎖能力變得異常簡單,支持spring boot,和spirng mvc等spring相關項目

快速開始

pring boot項目接入

添加lock starter組件依賴

<dependency>
?<groupId>cn.keking</groupId>
?<artifactId>spring-boot-klock-starter</artifactId>
?<version>1.3-RELEASE</version>
</dependency>
2.application.properties配置redis鏈接:spring.klock.address=127.0.0.1:6379

3.在需要加分布式鎖的方法上,添加注解@Klock,如:

redis的分布式鎖組件,簡單方便快捷接入使項目擁有分布式鎖


支持鎖指定的業(yè)務key,如同一個方法ID入?yún)⑾嗤募渔i,其他的放行。業(yè)務key的獲取支持Spel,具體使用方式如下

redis的分布式鎖組件,簡單方便快捷接入使項目擁有分布式鎖


spring mvc項目接入

其他步驟和spring boot步驟一樣,只需要spring-xx.xml配置中添加KlockAutoConfiguration類掃描即可,如:

<context:component-scan?base-package="org.springframework.boot.autoconfigure.klock.KlockAutoConfiguration"/>

使用參數(shù)說明

配置參數(shù)說明

spring.klock.address?:?redis鏈接地址
spring.klock.password?:?redis密碼
spring.klock.database?:?redis數(shù)據(jù)索引
spring.klock.waitTime?:?獲取鎖最長阻塞時間(默認:60,單位:秒)
spring.klock.leaseTime:?已獲取鎖后自動釋放時間(默認:60,單位:秒)
spring.klock.cluster-server.node-addresses?:?redis集群配置?如?127.0.0.1:7000,127.0.0.1:7001,127.0.0.1:7002
spring.klock.address?和?spring.klock.cluster-server.node-addresses?選其一即可

@Klock注解參數(shù)說明

@Klock可以標注四個參數(shù),作用分別如下
name:lock的name,對應redis的key值。默認為:類名+方法名
lockType:鎖的類型,目前支持(可重入鎖,公平鎖,讀寫鎖)。默認為:公平鎖
waitTime:獲取鎖最長等待時間。默認為:60s。同時也可通過spring.klock.waitTime統(tǒng)一配置
leaseTime:獲得鎖后,自動釋放鎖的時間。默認為:60s。同時也可通過spring.klock.leaseTime統(tǒng)一配置
lockTimeoutStrategy:?加鎖超時的處理策略,可配置為不做處理、快速失敗、阻塞等待的處理策略,默認策略為不做處理
customLockTimeoutStrategy:?自定義加鎖超時的處理策略,需指定自定義處理的方法的方法名,并保持入?yún)⒁恢隆?releaseTimeoutStrategy:?釋放鎖時,持有的鎖已超時的處理策略,可配置為不做處理、快速失敗的處理策略,默認策略為不做處理
customReleaseTimeoutStrategy:?自定義釋放鎖時,需指定自定義處理的方法的方法名,并保持入?yún)⒁恢隆?/pre>

鎖超時說明

因為基于redis實現(xiàn)分布式鎖,如果使用不當,會在以下場景下遇到鎖超時的問題:

redis的分布式鎖組件,簡單方便快捷接入使項目擁有分布式鎖


加鎖超時處理策略(LockTimeoutStrategy):

  • NO_OPERATION 不做處理,繼續(xù)執(zhí)行業(yè)務邏輯

  • FAIL_FAST 快速失敗,會拋出KlockTimeoutException

  • KEEP_ACQUIRE 阻塞等待,一直阻塞,直到獲得鎖,但在太多的嘗試后,會停止獲取鎖并報錯,此時很有可能是發(fā)生了死鎖。

  • 自定義(customLockTimeoutStrategy) 需指定自定義處理的方法的方法名,并保持入?yún)⒁恢拢付ㄗ远x處理方法后,會覆蓋上述三種策略,且會攔截業(yè)務邏輯的運行。

釋放鎖時超時處理策略(ReleaseTimeoutStrategy):

  • NO_OPERATION 不做處理,繼續(xù)執(zhí)行業(yè)務邏輯

  • FAIL_FAST 快速失敗,會拋出KlockTimeoutException

  • 自定義(customReleaseTimeoutStrategy) 需指定自定義處理的方法的方法名,并保持入?yún)⒁恢?,指定自定義處理方法后,會覆蓋上述兩種策略, 執(zhí)行自定義處理方法時,業(yè)務邏輯已經(jīng)執(zhí)行完畢,會在方法返回前和throw異常前執(zhí)行。

希望使用者清楚的意識到,如果沒有對加鎖超時進行有效的設置,那么設置釋放鎖時超時處理策略是沒有意義的。

在測試模塊中已集成鎖超時策略的使用用例

工程test模塊下,為分布式鎖的測試模塊??梢钥焖袤w驗分布式鎖的效果。


向AI問一下細節(jié)

免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權內(nèi)容。

AI