Redis中Redisson紅鎖(Redlock)使用原理
簡介
說明
本文介紹為什么要使用Redis的紅鎖(Redlock)、什么是Redis的紅鎖以及Redis紅鎖的原理。
本文用Redisson來介紹Redis紅鎖的用法。
Redisson 高版本會根據(jù)redisClient的模式來決定getLock返回的鎖類型,如果集群模式,滿足紅鎖的條件,則會直接返回紅鎖。
官網(wǎng)
REDIS distlock -- Redis中國用戶組(CRUG)
為什么使用Redis的紅鎖
主從結(jié)構(gòu)分布式鎖的問題
實現(xiàn)Redis分布式鎖的最簡單的方法就是在Redis中創(chuàng)建一個key,這個key有一個失效時間(TTL),以保證鎖最終會被自動釋放掉。當(dāng)客戶端釋放資源(解鎖)的時候,會刪除掉這個key。
從表面上看似乎效果不錯,但有一個嚴(yán)重的單點失敗問題:如果Redis掛了怎么辦?你可能會說,可以通過增加一個slave節(jié)點解決這個問題。但這通常是行不通的。這樣做,我們不能實現(xiàn)資源的獨享,因為Redis的主從同步通常是異步的。
在這種場景(主從結(jié)構(gòu))中存在明顯的競態(tài):
- 客戶端A從master獲取到鎖
- 在master將鎖同步到slave之前,master宕掉了。
- slave節(jié)點被晉級為master節(jié)點
- 客戶端B從新的master獲取到鎖
- 這個鎖對應(yīng)的資源之前已經(jīng)被客戶端A已經(jīng)獲取到了。安全失效!
有時候程序就是這么巧,比如說正好一個節(jié)點掛掉的時候,多個客戶端同時取到了鎖。如果你可以接受這種小概率錯誤,那用這個基于復(fù)制的方案就完全沒有問題。否則的話,我們建議你實現(xiàn)下面描述的解決方案。
解決方案:使用紅鎖
簡介
Redis中針對此種情況,引入了紅鎖的概念。紅鎖采用主節(jié)點過半機制,即獲取鎖或者釋放鎖成功的標(biāo)志為:在過半的節(jié)點上操作成功。
原理
在Redis的分布式環(huán)境中,我們假設(shè)有N個Redis master。這些節(jié)點完全互相獨立,不存在主從復(fù)制或者其他集群協(xié)調(diào)機制。之前我們已經(jīng)描述了在Redis單實例下怎么安全地獲取和釋放鎖。我們確保將在每(N)個實例上使用此方法獲取和釋放鎖。在這個樣例中,我們假設(shè)有5個Redis master節(jié)點,這是一個比較合理的設(shè)置,所以我們需要在5臺機器上面或者5臺虛擬機上面運行這些實例,這樣保證他們不會同時都宕掉。
為了取到鎖,客戶端應(yīng)該執(zhí)行以下操作:
- 獲取當(dāng)前Unix時間,以毫秒為單位。
- 依次嘗試從N個實例,使用相同的key和隨機值獲取鎖。
- 向Redis設(shè)置鎖時,客戶端應(yīng)該設(shè)置一個網(wǎng)絡(luò)連接和響應(yīng)超時時間,這個超時時間應(yīng)該小于鎖的失效時間。
- 例如你的鎖自動失效時間為10秒,則超時時間應(yīng)該在5-50毫秒之間。這樣可以避免服務(wù)器端Redis已經(jīng)掛掉的情況下,客戶端還在死死地等待響應(yīng)結(jié)果。如果服務(wù)器端沒有在規(guī)定時間內(nèi)響應(yīng),客戶端應(yīng)該盡快嘗試另外一個Redis實例。
- 客戶端使用當(dāng)前時間減去開始獲取鎖時間(步驟1記錄的時間)得到獲取鎖使用的時間。
- 僅當(dāng)從大多數(shù)(這里是3個節(jié)點)的Redis節(jié)點都取到鎖,且使用的時間小于鎖失效時間時,鎖才算獲取成功。
- 如果取到了鎖,key的真正有效時間等于有效時間減去獲取鎖所使用的時間(步驟3計算的結(jié)果)。
- 如果因為某些原因,獲取鎖失?。]有在至少N/2+1個Redis實例取到鎖或者取鎖時間已經(jīng)超過了有效時間),客戶端應(yīng)該在所有的Redis實例上進行解鎖(即便某些Redis實例根本就沒有加鎖成功)。
Redisson紅鎖實例
官網(wǎng)
官方github:8. 分布式鎖和同步器 · redisson/redisson Wik
基于Redis的Redisson紅鎖RedissonRedLock對象實現(xiàn)了Redlock介紹的加鎖算法。該對象也可以用來將多個RLock對象關(guān)聯(lián)為一個紅鎖,每個RLock對象實例可以來自于不同的Redisson實例。
RLock lock1 = redissonInstance1.getLock("lock1"); RLock lock2 = redissonInstance2.getLock("lock2"); RLock lock3 = redissonInstance3.getLock("lock3"); RedissonRedLock lock = new RedissonRedLock(lock1, lock2, lock3); // 同時加鎖:lock1 lock2 lock3 // 紅鎖在大部分節(jié)點上加鎖成功就算成功。 lock.lock(); ... lock.unlock();
大家都知道,如果負(fù)責(zé)儲存某些分布式鎖的某些Redis節(jié)點宕機以后,而且這些鎖正好處于鎖住的狀態(tài)時,這些鎖會出現(xiàn)鎖死的狀態(tài)。為了避免這種情況的發(fā)生,Redisson內(nèi)部提供了一個監(jiān)控鎖的看門狗,它的作用是在Redisson實例被關(guān)閉前,不斷的延長鎖的有效期。默認(rèn)情況下,看門狗的檢查鎖的超時時間是30秒鐘,也可以通過修改Config.lockWatchdogTimeout來另行指定。
另外Redisson還通過加鎖的方法提供了leaseTime的參數(shù)來指定加鎖的時間。超過這個時間后鎖便自動解開了。
RedissonRedLock lock = new RedissonRedLock(lock1, lock2, lock3); // 給lock1,lock2,lock3加鎖,如果沒有手動解開的話,10秒鐘后將會自動解開 lock.lock(10, TimeUnit.SECONDS); // 為加鎖等待100秒時間,并在加鎖成功10秒鐘后自動解開 boolean res = lock.tryLock(100, 10, TimeUnit.SECONDS); ... lock.unlock();
Redisson紅鎖原理
RedissonRedLock extends RedissonMultiLock,所以實際上,redLock.tryLock實際調(diào)用:org.redisson.RedissonMultiLock.java#tryLock(),進而調(diào)用到其同類的tryLock(long waitTime, long leaseTime, TimeUnit unit) ,入?yún)椋簍ryLock(-1, -1, null)
org.redisson.RedissonMultiLock.java#tryLock(long waitTime, long leaseTime, TimeUnit unit)源碼如下:
final List<RLock> locks = new ArrayList<>(); ? /** ?* Creates instance with multiple {@link RLock} objects. ?* Each RLock object could be created by own Redisson instance. ?* ?* @param locks - array of locks ?*/ public RedissonMultiLock(RLock... locks) { ?? ?if (locks.length == 0) { ?? ??? ?throw new IllegalArgumentException("Lock objects are not defined"); ?? ?} ?? ?this.locks.addAll(Arrays.asList(locks)); } ? 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)到達(dá) 允許加鎖失敗節(jié)點個數(shù)限制 (N-(N/2+1)) ? ? ? ? ? ? ?* 如果已經(jīng)到達(dá), 就認(rèn)定最終申請鎖失敗,則沒有必要繼續(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)等于最大等待時間,則認(rèn)定最終申請鎖失敗,返回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í)行完則認(rèn)為最終申請鎖成功,返回true ? ? ?*/ ? ? return true; }
參考文章
到此這篇關(guān)于Redis中Redisson紅鎖(Redlock)使用原理的文章就介紹到這了,更多相關(guān)Redis Redisson紅鎖內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
Redis教程(四):Hashes數(shù)據(jù)類型
這篇文章主要介紹了Redis教程(四):Hashes數(shù)據(jù)類型,本文講解了Hashes數(shù)據(jù)類型概述、相關(guān)命令列表和命令使用示例等內(nèi)容,需要的朋友可以參考下2015-04-04超強、超詳細(xì)Redis數(shù)據(jù)庫入門教程
這篇文章主要介紹了超強、超詳細(xì)Redis入門教程,本文詳細(xì)介紹了Redis數(shù)據(jù)庫各個方面的知識,需要的朋友可以參考下2014-10-10Redis Cluster集群動態(tài)擴容的實現(xiàn)
本文主要介紹了Redis Cluster集群動態(tài)擴容的實現(xiàn),文中通過示例代碼介紹的非常詳細(xì),需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2021-07-07詳談redis優(yōu)化配置和redis.conf說明(推薦)
下面小編就為大家?guī)硪黄斦剅edis優(yōu)化配置和redis.conf說明(推薦)。小編覺得挺不錯的,現(xiàn)在就分享給大家,也給大家做個參考。一起跟隨小編過來看看吧2017-03-03