拜託，面試請不要再問我Redis分佈式鎖的實現原理！【石杉的架構筆記】

歡迎關注我的公衆號：石杉的架構筆記（ID:shishan100）

週一至五早8點半！精品技術文章準時送上！

目錄

1、寫在前面

2、Redisson實現Redis分佈式鎖的底層原理

      （1）加鎖機制

      （2）鎖互斥機制

      （3）watch dog自動延期機制

      （4）可重入加鎖機制

      （5）鎖釋放機制

      （6）此種方案Redis分佈式鎖的缺陷

3、未完待續

1、寫在前面

如今面試，通常都會聊聊分佈式系統這塊的東西。一般面試官都會從服務框架（Spring Cloud、Dubbo）聊起，一路聊到分佈式事務、分佈式鎖、ZooKeeper等知識。因此我們這篇文章就來聊聊分佈式鎖這塊知識，具體的來看看Redis分佈式鎖的實現原理。

說實話，若是在公司裏落地生產環境用分佈式鎖的時候，必定是會用開源類庫的，好比Redis分佈式鎖，通常就是用Redisson框架就行了，很是的簡便易用。

你們若是有興趣，能夠去看看Redisson的官網，看看如何在項目中引入Redisson的依賴，而後基於Redis實現分佈式鎖的加鎖與釋放鎖。下面給你們看一段簡單的使用代碼片斷，先直觀的感覺一下：

怎麼樣，上面那段代碼，是否是感受簡單的不行！此外，人家還支持redis單實例、redis哨兵、redis cluster、redis master-slave等各類部署架構，均可以給你完美實現。

2、Redisson實現Redis分佈式鎖的底層原理

好的，接下來就經過一張手繪圖，給你們說說Redisson這個開源框架對Redis分佈式鎖的實現原理。

（1）加鎖機制

我們來看上面那張圖，如今某個客戶端要加鎖。若是該客戶端面對的是一個redis cluster集羣，他首先會根據hash節點選擇一臺機器。這裏注意，僅僅只是選擇一臺機器！這點很關鍵！緊接着，就會發送一段lua腳本到redis上，那段lua腳本以下所示：

爲啥要用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數據結構，這行命令執行後，會出現一個相似下面的數據結構：

上述就表明「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都已經持有了這把鎖了，結果可重入的加鎖會怎麼樣呢？好比下面這種代碼：

這時咱們來分析一下上面那段lua腳本。第一個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數據結構變爲下面這樣：

你們看到了吧，那個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實例宕機的時候，可能致使多個客戶端同時完成加鎖。

3、未完待續

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

敬請關注：

《每秒上千訂單的高併發場景下如何完成分佈式鎖的性能優化？》

END

若有收穫，請幫忙轉發，您的鼓勵是做者最大的動力，謝謝！

一大波微服務、分佈式、高併發、高可用的原創系列

文章正在路上,歡迎掃描下方二維碼，持續關注：

石杉的架構筆記（id:shishan100）

十餘年BAT架構經驗傾囊相授

推薦閱讀：
一、 拜託！面試請不要再問我Spring Cloud底層原理
二、 【雙11狂歡的背後】微服務註冊中心如何承載大型系統的千萬級訪問？
三、 【性能優化之道】每秒上萬併發下的Spring Cloud參數優化實戰
四、 微服務架構如何保障雙11狂歡下的99.99%高可用
五、 兄弟，用大白話告訴你小白都能聽懂的Hadoop架構原理
六、 大規模集羣下Hadoop NameNode如何承載每秒上千次的高併發訪問
七、【 性能優化的祕密】Hadoop如何將TB級大文件的上傳性能優化上百倍

八、 拜託，面試請不要再問我TCC分佈式事務的實現原理 坑爹呀！

九、 【坑爹呀！】最終一致性分佈式事務如何保障實際生產中99.99%高可用？