Redis分布式鎖之紅鎖的實現(xiàn)
一、問題
分布式鎖,當(dāng)我們請求一個分布式鎖的時候,成功了,但是這時候slave還沒有復(fù)制我們的鎖,masterDown了,我們的應(yīng)用繼續(xù)請求鎖的時候,會從繼任了master的原slave上申請,也會成功。
這就會導(dǎo)致,同一個鎖被獲取了不止一次。
二、辦法
Redis中針對此種情況,引入了紅鎖的概念。
三、原理
用Redis中的多個master實例,來獲取鎖,只有大多數(shù)實例獲取到了鎖,才算是獲取成功。具體的紅鎖算法分為以下五步:
- 獲取當(dāng)前的時間(單位是毫秒)。
- 使用相同的key和隨機值在N個節(jié)點上請求鎖。這里獲取鎖的嘗試時間要遠遠小于鎖的超時時間,防止某個masterDown了,我們還在不斷的獲取鎖,而被阻塞過長的時間。
- 只有在大多數(shù)節(jié)點上獲取到了鎖,而且總的獲取時間小于鎖的超時時間的情況下,認為鎖獲取成功了。
- 如果鎖獲取成功了,鎖的超時時間就是最初的鎖超時時間進去獲取鎖的總耗時時間。
- 如果鎖獲取失敗了,不管是因為獲取成功的節(jié)點的數(shù)目沒有過半,還是因為獲取鎖的耗時超過了鎖的釋放時間,都會將已經(jīng)設(shè)置了key的master上的key刪除。
四、實戰(zhàn)
Redission就實現(xiàn)了紅鎖算法,使用的步驟如下:
1、引入maven
<!-- JDK 1.8+ compatible --> <dependency> <groupId>org.redisson</groupId> <artifactId>redisson</artifactId> <version>3.9.0</version> </dependency>
2、引入代碼
Config config1 = new Config();
config1.useSingleServer().setAddress("redis://172.0.0.1:5378").setPassword("a123456").setDatabase(0);
RedissonClient redissonClient1 = Redisson.create(config1);
Config config2 = new Config();
config2.useSingleServer().setAddress("redis://172.0.0.1:5379").setPassword("a123456").setDatabase(0);
RedissonClient redissonClient2 = Redisson.create(config2);
Config config3 = new Config();
config3.useSingleServer().setAddress("redis://172.0.0.1:5380").setPassword("a123456").setDatabase(0);
RedissonClient redissonClient3 = Redisson.create(config3);
/**
?* 獲取多個 RLock 對象
?*/
RLock lock1 = redissonClient1.getLock(lockKey);
RLock lock2 = redissonClient2.getLock(lockKey);
RLock lock3 = redissonClient3.getLock(lockKey);
/**
?* 根據(jù)多個 RLock 對象構(gòu)建 RedissonRedLock (最核心的差別就在這里)
?*/
RedissonRedLock redLock = new RedissonRedLock(lock1, lock2, lock3);
try {
? ? /**
? ? ?* 4.嘗試獲取鎖
? ? ?* waitTimeout 嘗試獲取鎖的最大等待時間,超過這個值,則認為獲取鎖失敗
? ? ?* leaseTime ? 鎖的持有時間,超過這個時間鎖會自動失效(值應(yīng)設(shè)置為大于業(yè)務(wù)處理的時間,確保在鎖有效期內(nèi)業(yè)務(wù)能處理完)
? ? ?*/
? ? boolean res = redLock.tryLock((long)waitTimeout, (long)leaseTime, TimeUnit.SECONDS);
? ? if (res) {
? ? ? ? //成功獲得鎖,在這里處理業(yè)務(wù)
? ? }
} catch (Exception e) {
? ? throw new RuntimeException("aquire lock fail");
}finally{
? ? //無論如何, 最后都要解鎖
? ? redLock.unlock();
}3、核心源碼
public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException {
? ? long newLeaseTime = -1;
? ? if (leaseTime != -1) {
? ? ? ? newLeaseTime = unit.toMillis(waitTime)*2;
? ? }
? ??
? ? long time = System.currentTimeMillis();
? ? long remainTime = -1;
? ? if (waitTime != -1) {
? ? ? ? remainTime = unit.toMillis(waitTime);
? ? }
? ? long lockWaitTime = calcLockWaitTime(remainTime);
? ? /**
? ? ?* 1. 允許加鎖失敗節(jié)點個數(shù)限制(N-(N/2+1))
? ? ?*/
? ? int failedLocksLimit = failedLocksLimit();
? ? /**
? ? ?* 2. 遍歷所有節(jié)點通過EVAL命令執(zhí)行l(wèi)ua加鎖
? ? ?*/
? ? List<RLock> acquiredLocks = new ArrayList<>(locks.size());
? ? for (ListIterator<RLock> iterator = locks.listIterator(); iterator.hasNext();) {
? ? ? ? RLock lock = iterator.next();
? ? ? ? boolean lockAcquired;
? ? ? ? /**
? ? ? ? ?* ?3.對節(jié)點嘗試加鎖
? ? ? ? ?*/
? ? ? ? try {
? ? ? ? ? ? if (waitTime == -1 && leaseTime == -1) {
? ? ? ? ? ? ? ? lockAcquired = lock.tryLock();
? ? ? ? ? ? } else {
? ? ? ? ? ? ? ? long awaitTime = Math.min(lockWaitTime, remainTime);
? ? ? ? ? ? ? ? lockAcquired = lock.tryLock(awaitTime, newLeaseTime, TimeUnit.MILLISECONDS);
? ? ? ? ? ? }
? ? ? ? } catch (RedisResponseTimeoutException e) {
? ? ? ? ? ? // 如果拋出這類異常,為了防止加鎖成功,但是響應(yīng)失敗,需要解鎖所有節(jié)點
? ? ? ? ? ? unlockInner(Arrays.asList(lock));
? ? ? ? ? ? lockAcquired = false;
? ? ? ? } catch (Exception e) {
? ? ? ? ? ? // 拋出異常表示獲取鎖失敗
? ? ? ? ? ? lockAcquired = false;
? ? ? ? }
? ? ? ??
? ? ? ? if (lockAcquired) {
? ? ? ? ? ? /**
? ? ? ? ? ? ?*4. 如果獲取到鎖則添加到已獲取鎖集合中
? ? ? ? ? ? ?*/
? ? ? ? ? ? acquiredLocks.add(lock);
? ? ? ? } else {
? ? ? ? ? ? /**
? ? ? ? ? ? ?* 5. 計算已經(jīng)申請鎖失敗的節(jié)點是否已經(jīng)到達 允許加鎖失敗節(jié)點個數(shù)限制 (N-(N/2+1))
? ? ? ? ? ? ?* 如果已經(jīng)到達, 就認定最終申請鎖失敗,則沒有必要繼續(xù)從后面的節(jié)點申請了
? ? ? ? ? ? ?* 因為 Redlock 算法要求至少N/2+1 個節(jié)點都加鎖成功,才算最終的鎖申請成功
? ? ? ? ? ? ?*/
? ? ? ? ? ? if (locks.size() - acquiredLocks.size() == failedLocksLimit()) {
? ? ? ? ? ? ? ? break;
? ? ? ? ? ? }
? ? ? ? ? ? if (failedLocksLimit == 0) {
? ? ? ? ? ? ? ? unlockInner(acquiredLocks);
? ? ? ? ? ? ? ? if (waitTime == -1 && leaseTime == -1) {
? ? ? ? ? ? ? ? ? ? return false;
? ? ? ? ? ? ? ? }
? ? ? ? ? ? ? ? failedLocksLimit = failedLocksLimit();
? ? ? ? ? ? ? ? acquiredLocks.clear();
? ? ? ? ? ? ? ? // reset iterator
? ? ? ? ? ? ? ? while (iterator.hasPrevious()) {
? ? ? ? ? ? ? ? ? ? iterator.previous();
? ? ? ? ? ? ? ? }
? ? ? ? ? ? } else {
? ? ? ? ? ? ? ? failedLocksLimit--;
? ? ? ? ? ? }
? ? ? ? }
? ? ? ? /**
? ? ? ? ?* 6.計算 目前從各個節(jié)點獲取鎖已經(jīng)消耗的總時間,如果已經(jīng)等于最大等待時間,則認定最終申請鎖失敗,返回false
? ? ? ? ?*/
? ? ? ? if (remainTime != -1) {
? ? ? ? ? ? remainTime -= System.currentTimeMillis() - time;
? ? ? ? ? ? time = System.currentTimeMillis();
? ? ? ? ? ? if (remainTime <= 0) {
? ? ? ? ? ? ? ? unlockInner(acquiredLocks);
? ? ? ? ? ? ? ? return false;
? ? ? ? ? ? }
? ? ? ? }
? ? }
? ? if (leaseTime != -1) {
? ? ? ? List<RFuture<Boolean>> futures = new ArrayList<>(acquiredLocks.size());
? ? ? ? for (RLock rLock : acquiredLocks) {
? ? ? ? ? ? RFuture<Boolean> future = ((RedissonLock) rLock).expireAsync(unit.toMillis(leaseTime), TimeUnit.MILLISECONDS);
? ? ? ? ? ? futures.add(future);
? ? ? ? }
? ? ? ??
? ? ? ? for (RFuture<Boolean> rFuture : futures) {
? ? ? ? ? ? rFuture.syncUninterruptibly();
? ? ? ? }
? ? }
? ? /**
? ? ?* 7.如果邏輯正常執(zhí)行完則認為最終申請鎖成功,返回true
? ? ?*/
? ? return true;
}到此這篇關(guān)于Redis分布式鎖之紅鎖的實現(xiàn)的文章就介紹到這了,更多相關(guān)Redis 紅鎖內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
Redis緩存lettuce更換為Jedis的實現(xiàn)步驟
在springboot中引入spring-boot-starter-data-redis依賴時,默認使用的是lettuce,如果不想使用lettuce而是使用Jedis連接池,本文主要介紹了Redis緩存lettuce更換為Jedis的實現(xiàn)步驟,感興趣的可以了解一下2024-08-08
CentOS7.5使用mysql_multi方式安裝MySQL5.7.28多實例(詳解)
這篇文章主要介紹了CentOS7.5使用mysql_multi方式安裝MySQL5.7.28多實例,非常不錯,具有一定的參考借鑒價值,需要的朋友可以參考下2020-01-01

