天天看點

redis分布式鎖 Redisson的原理

一、寫在前面

現在面試,一般都會聊聊分布式系統這塊的東西。通常面試官都會從服務架構(Spring Cloud、Dubbo)聊起,一路聊到分布式事務、分布式鎖、ZooKeeper等知識。

是以咱們這篇文章就來聊聊分布式鎖這塊知識,具體的來看看Redis分布式鎖的實作原理。

說實話,如果在公司裡落地生産環境用分布式鎖的時候,一定是會用開源類庫的,比如Redis分布式鎖,一般就是用Redisson架構就好了,非常的簡便易用。

大家如果有興趣,可以去看看Redisson的官網,看看如何在項目中引入Redisson的依賴,然後基于Redis實作分布式鎖的加鎖與釋放鎖。

下面給大家看一段簡單的使用代碼片段,先直覺的感受一下:

redis分布式鎖 Redisson的原理

怎麼樣,上面那段代碼,是不是感覺簡單的不行!

此外,人家還支援redis單執行個體、redis哨兵、redis cluster、redis master-slave等各種部署架構,都可以給你完美實作。

二、Redisson實作Redis分布式鎖的底層原理

好的,接下來就通過一張手繪圖,給大家說說Redisson這個開源架構對Redis分布式鎖的實作原理。

redis分布式鎖 Redisson的原理

(1)加鎖機制

咱們來看上面那張圖,現在某個用戶端要加鎖,如果該用戶端面對的是一個redis cluster叢集,他首先會根據hash節點選擇一台機器。

這裡注意,僅僅隻是選擇一台機器!這點很關鍵!

緊接着,就會發送一段lua腳本到redis上,那段lua腳本如下所示:

redis分布式鎖 Redisson的原理

為啥要用lua腳本呢?

因為一大坨複雜的業務邏輯,可以通過封裝在lua腳本中發送給redis,保證這段複雜業務邏輯執行的原子性。

那麼,這段lua腳本是什麼意思呢?

KEYS[1]代表的是你加鎖的那個key,比如說:

RLock lock = redisson.getLock("myLock");

這裡你自己設定了加鎖的那個鎖key就是“myLock”。

ARGV[1]代表的就是鎖key的預設生存時間,預設30秒。

ARGV[2]代表的是加鎖的用戶端的ID,類似于下面這樣:

8743c9c0-0795-4907-87fd-6c719a6b4586:1

給大家解釋一下,第一段if判斷語句,就是用“exists myLock”指令判斷一下,如果你要加鎖的那個鎖key不存在的話,你就進行加鎖。

如何加鎖呢?很簡單,用下面的指令:

hset myLock  8743c9c0-0795-4907-87fd-6c719a6b4586:1 1

通過這個指令設定一個hash資料結構,這行指令執行後,會出現一個類似下面的資料結構:

redis分布式鎖 Redisson的原理

上述就代表“8743c9c0-0795-4907-87fd-6c719a6b4586:1”這個用戶端對“myLock”這個鎖key完成了加鎖。

接着會執行“pexpire myLock 30000”指令,設定myLock這個鎖key的生存時間是30秒。

好了,到此為止,ok,加鎖完成了。

(2)鎖互斥機制

那麼在這個時候,如果用戶端2來嘗試加鎖,執行了同樣的一段lua腳本,會咋樣呢?

很簡單,第一個if判斷會執行“exists myLock”,發現myLock這個鎖key已經存在了。

接着第二個if判斷,判斷一下,myLock鎖key的hash資料結構中,是否包含用戶端2的ID,但是明顯不包含,因為那裡包含的是用戶端1的ID。

是以,用戶端2會擷取到pttl myLock傳回的一個數字,這個數字代表了myLock這個鎖key的剩餘生存時間。比如還剩15000毫秒的生存時間。

此時用戶端2會進入一個while循環,不停的嘗試加鎖。

(3)watch dog自動延期機制

用戶端1加鎖的鎖key預設生存時間才30秒,如果超過了30秒,用戶端1還想一直持有這把鎖,怎麼辦呢?

簡單!隻要用戶端1一旦加鎖成功,就會啟動一個watch dog看門狗,他是一個背景線程,會每隔10秒檢查一下,如果用戶端1還持有鎖key,那麼就會不斷的延長鎖key的生存時間。

(4)可重入加鎖機制

那如果用戶端1都已經持有了這把鎖了,結果可重入的加鎖會怎麼樣呢?

比如下面這種代碼:

redis分布式鎖 Redisson的原理

這時我們重新來過一下上面那段lua腳本。

執行第二次lock時的判斷流程:

第一個if判斷肯定不成立,“exists myLock”會顯示鎖key已經存在了。

第二個if判斷會成立,因為myLock的hash資料結構中包含的那個ID,就是用戶端1的那個ID,也就是“8743c9c0-0795-4907-87fd-6c719a6b4586:1”

此時就會執行可重入加鎖的邏輯,他會用:

incrby myLock 

 8743c9c0-0795-4907-87fd-6c71a6b4586:1 1

通過這個指令,對用戶端1的加鎖次數,累加1。

此時myLock資料結構變為下面這樣:

redis分布式鎖 Redisson的原理

大家看到了吧,那個myLock的hash資料結構中的那個用戶端ID,就對應着加鎖的次數

(5)釋放鎖機制

如果執行lock.unlock(),就可以釋放分布式鎖,此時的業務邏輯也是非常簡單的。

其實說白了,就是每次都對myLock資料結構中的那個加鎖次數減1。

如果發現加鎖次數是0了,說明這個用戶端已經不再持有鎖了,此時就會用:

“del myLock”指令,從redis裡删除這個key。

然後呢,另外的用戶端2就可以嘗試完成加鎖了。

這就是所謂的分布式鎖的開源Redisson架構的實作機制。

一般我們在生産系統中,可以用Redisson架構提供的這個類庫來基于redis進行分布式鎖的加鎖與釋放鎖。

(6)上述Redis分布式鎖的缺點

其實上面那種方案最大的問題,就是如果你對某個redis master執行個體,寫入了myLock這種鎖key的value,此時會異步複制給對應的master slave執行個體。

但是這個過程中一旦發生redis master當機,主備切換,redis slave變為了redis master。

接着就會導緻,用戶端2來嘗試加鎖的時候,在新的redis master上完成了加鎖,而用戶端1也以為自己成功加了鎖。

此時就會導緻多個用戶端對一個分布式鎖完成了加鎖。

這時系統在業務語義上一定會出現問題,導緻各種髒資料的産生。

是以這個就是redis cluster,或者是redis master-slave架構的主從異步複制導緻的redis分布式鎖的最大缺陷:在redis master執行個體當機的時候,可能導緻多個用戶端同時完成加鎖。

三、未完待續

下一篇文章,給大家分享一下電商系統中,大促銷的活動場景下,每秒上千訂單的時候如何對Redis分布式鎖進行高并發的優化。

繼續閱讀