1 介紹

這篇博文講介紹如何一步步構建一個基於Redis的分佈式鎖。會從最原始的版本開始，然後根據問題進行調整，最後完成一個較為合理的分佈式鎖。

本篇文章會將分佈式鎖的實現分為兩部分，一個是單機環境，另一個是集群環境下的Redis鎖實現。在介紹分佈式鎖的實現之前，先來了解下分佈式鎖的一些信息。

2 分佈式鎖

2.1 什麼是分佈式鎖？

分佈式鎖是控制分佈式系統或不同系統之間共同訪問共享資源的一種鎖實現，如果不同的系統或同一個系統的不同主機之間共享了某個資源時，往往需要互斥來防止彼此干擾來保證一致性。

2.2 分佈式鎖需要具備哪些條件

1. 互斥性：在任意一個時刻，只有一個客戶端持有鎖。
2. 無死鎖：即便持有鎖的客戶端崩潰或者其他意外事件，鎖仍然可以被獲取。
3. 容錯：只要大部分Redis節點都活著，客戶端就可以獲取和釋放鎖

2.4 分佈式鎖的實現有哪些？

1. 數據庫
2. Memcached（add命令）
3. Redis（setnx命令）
4. Zookeeper（臨時節點）
5. 等等

3 單機Redis的分佈式鎖

3.1 準備工作

3.1.1 定義常量類

3.1.2 定義鎖的抽象類

抽象類RedisLock實現java.util.concurrent包下的Lock接口，然後對一些方法提供默認實現，子類只需實現lock方法和unlock方法即可。代碼如下

3.2 最基礎的版本1

先來一個最基礎的版本，代碼如下

LockCase1類提供了lock和unlock方法。

其中lock方法也就是在reids客戶端執行如下命令

SET lockKey value NX

而unlock方法就是調用DEL命令將鍵刪除。

好了，方法介紹完了。現在來想想這其中會有什麼問題？

假設有兩個客戶端A和B，A獲取到分佈式的鎖。A執行了一會，突然A所在的服務器斷電了（或者其他什麼的），也就是客戶端A掛了。這時出現一個問題，這個鎖一直存在，且不會被釋放，其他客戶端永遠獲取不到鎖。如下示意圖

可以通過設置過期時間來解決這個問題

3.3 版本2-設置鎖的過期時間

類似的Redis命令如下

SET lockKey value NX EX 30

注：要保證設置過期時間和設置鎖具有原子性

這時又出現一個問題，問題出現的步驟如下

1. 客戶端A獲取鎖成功，過期時間30秒。
2. 客戶端A在某個操作上阻塞了50秒。
3. 30秒時間到了，鎖自動釋放了。
4. 客戶端B獲取到了對應同一個資源的鎖。
5. 客戶端A從阻塞中恢復過來，釋放掉了客戶端B持有的鎖。

示意圖如下

這時會有兩個問題

1. 過期時間如何保證大於業務執行時間?
2. 如何保證鎖不會被誤刪除?

先來解決如何保證鎖不會被誤刪除這個問題。

這個問題可以通過設置value為當前客戶端生成的一個隨機字符串，且保證在足夠長的一段時間內在所有客戶端的所有獲取鎖的請求中都是唯一的。

版本2的完整代碼：Github地址：https://link.juejin.im/?target=https%3A%2F%2Fgithub.com%2Frainbowda%2FlearnWay%2Fblob%2Fmaster%2FlearnRedis%2Fdistributed-locks%2Fsrc%2Fmain%2Fjava%2Fcom%2FlearnRedis%2Flock%2Fcase2%2FLockCase2.java

3.4 版本3-設置鎖的value

抽象類RedisLock增加lockValue字段，lockValue字段的默認值為UUID隨機值假設當前線程ID。

加鎖代碼

解鎖代碼

這時看看加鎖代碼，好像沒有什麼問題啊。

再來看看解鎖的代碼，這裡的解鎖操作包含三步操作：獲取值、判斷和刪除鎖。這時你有沒有想到在多線程環境下的i++操作?

3.4.1 i++問題

i++操作也可分為三個步驟：讀i的值，進行i+1，設置i的值。

如果兩個線程同時對i進行i++操作，會出現如下情況

1. i設置值為0
2. 線程A讀到i的值為0
3. 線程B也讀到i的值為0
4. 線程A執行了+1操作，將結果值1寫入到內存
5. 線程B執行了+1操作，將結果值1寫入到內存
6. 此時i進行了兩次i++操作，但是結果卻為1

在多線程環境下有什麼方式可以避免這類情況發生?

解決方式有很多種，例如用AtomicInteger、CAS、synchronized等等。

這些解決方式的目的都是要確保i++ 操作的原子性。那麼回過頭來看看解鎖，同理我們也是要確保解鎖的原子性。我們可以利用Redis的lua腳本來實現解鎖操作的原子性。

版本3的完整代碼：Github地址：https://link.juejin.im/?target=https%3A%2F%2Fgithub.com%2Frainbowda%2FlearnWay%2Fblob%2Fmaster%2FlearnRedis%2Fdistributed-locks%2Fsrc%2Fmain%2Fjava%2Fcom%2FlearnRedis%2Flock%2Fcase3%2FLockCase3.java

3.5 版本4-具有原子性的釋放鎖

lua腳本內容如下

這段Lua腳本在執行的時候要把的lockValue作為ARGV[1]的值傳進去，把lockKey作為KEYS[1]的值傳進去。現在來看看解鎖的java代碼

好了，解鎖操作也確保了原子性了，那麼是不是單機Redis環境的分佈式鎖到此就完成了?

別忘了版本2-設置鎖的過期時間還有一個，過期時間如何保證大於業務執行時間問題沒有解決。

版本4的完整代碼：Github地址：https://link.juejin.im/?target=https%3A%2F%2Fgithub.com%2Frainbowda%2FlearnWay%2Fblob%2Fmaster%2FlearnRedis%2Fdistributed-locks%2Fsrc%2Fmain%2Fjava%2Fcom%2FlearnRedis%2Flock%2Fcase4%2FLockCase4.java

3.6 版本5-確保過期時間大於業務執行時間

抽象類RedisLock增加一個boolean類型的屬性isOpenExpirationRenewal，用來標識是否開啟定時刷新過期時間。

在增加一個scheduleExpirationRenewal方法用於開啟刷新過期時間的線程。

加鎖代碼在獲取鎖成功後將isOpenExpirationRenewal置為true，並且調用scheduleExpirationRenewal方法，開啟刷新過期時間的線程。

解鎖代碼增加一行代碼，將isOpenExpirationRenewal屬性置為false，停止刷新過期時間的線程輪詢。

版本5的完整代碼：Github地址：https://link.juejin.im/?target=https%3A%2F%2Fgithub.com%2Frainbowda%2FlearnWay%2Fblob%2Fmaster%2FlearnRedis%2Fdistributed-locks%2Fsrc%2Fmain%2Fjava%2Fcom%2FlearnRedis%2Flock%2Fcase5%2FLockCase5.java

3.7 測試

測試代碼如下

測試結果

或許到這裡基於單機Redis環境的分佈式就介紹完了。但是使用java的同學有沒有發現一個鎖的重要特性

那就是鎖的重入，那麼分佈式鎖的重入該如何實現呢？這裡就留一個坑了

4 集群Redis的分佈式鎖

在Redis的分佈式環境中，Redis 的作者提供了RedLock 的算法來實現一個分佈式鎖。

4.1 加鎖

RedLock算法加鎖步驟如下

1. 獲取當前Unix時間，以毫秒為單位。
2. 依次嘗試從N個實例，使用相同的key和隨機值獲取鎖。在步驟2，當向Redis設置鎖時,客戶端應該設置一個網絡連接和響應超時時間，這個超時時間應該小於鎖的失效時間。例如你的鎖自動失效時間為10秒，則超時時間應該在5-50毫秒之間。這樣可以避免服務器端Redis已經掛掉的情況下，客戶端還在死死地等待響應結果。如果服務器端沒有在規定時間內響應，客戶端應該儘快嘗試另外一個Redis實例。
3. 客戶端使用當前時間減去開始獲取鎖時間（步驟1記錄的時間）就得到獲取鎖使用的時間。當且僅當從大多數（這裡是3個節點）的Redis節點都取到鎖，並且使用的時間小於鎖失效時間時，鎖才算獲取成功。
4. 如果取到了鎖，key的真正有效時間等於有效時間減去獲取鎖所使用的時間（步驟3計算的結果）。
5. 如果因為某些原因，獲取鎖失敗（沒有在至少N/2+1個Redis實例取到鎖或者取鎖時間已經超過了有效時間），客戶端應該在所有的Redis實例上進行解鎖（即便某些Redis實例根本就沒有加鎖成功）。

4.2 解鎖

向所有的Redis實例發送釋放鎖命令即可，不用關心之前有沒有從Redis實例成功獲取到鎖.

關於RedLock算法，還有一個小插曲，就是Martin Kleppmann 和 RedLock 作者 antirez的對RedLock算法的互懟。 官網原話如下

Martin Kleppmann analyzed Redlock here. I disagree with the analysis and posted my reply to his analysis here.

更多關於RedLock算法這裡就不在說明，有興趣的可以到官網閱讀相關文章。

5 總結

這篇文章講述了一個基於Redis的分佈式鎖的編寫過程及解決問題的思路，但是本篇文章實現的分佈式鎖並不適合用於生產環境。java環境有 Redisson 可用於生產環境，但是分佈式鎖還是Zookeeper會比較好一些（可以看Martin Kleppmann 和 RedLock的分析）。

Martin Kleppmann對RedLock的分析：http://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html

RedLock 作者 antirez的回應：antirez.com/news/101

整個項目的地址存放在Github上，有需要的可以看看：Github地址：https://link.juejin.im/?target=https%3A%2F%2Fgithub.com%2Frainbowda%2FlearnWay%2Ftree%2Fmaster%2FlearnRedis%2Fdistributed-locks

閱讀更多 架構師的修煉之路 的文章

關鍵字: Redis 分佈式 基於