[[434468]]

Redis 分布式鎖這個話題似乎爛大街了，不管你是面試還是工作，隨處可見，「碼哥」為啥還要寫呢?

因為網(wǎng)上 99.99% 的文章都沒有真正的把分布式鎖說清楚，存在很多 bug。

今日，「碼哥」就跟大家深入分布式鎖的 G 點，系統(tǒng)的做一個寫好代碼掌握技巧的真男人。

在進入「高潮」之前，以下問題就當做「前戲」去思考，你能回答多少?

• 什么時候需要分布式鎖?
• 加、解鎖的代碼位置有講究么?
• 如何避免出現(xiàn)死鎖
• 超時時間設置多少合適呢?
• 如何避免鎖被其他線程釋放
• 如何實現(xiàn)重入鎖?
• 主從架構會帶來什么安全問題?
• 什么是 Redlock
• ……

為何需要分布式鎖?

碼哥，說個通俗的例子講解下什么時候需要分布式鎖呢?

精子噴射那一刻，億級流量沖向卵子，只有一個精子能獲得與卵子結(jié)合的幸運。

造物主為了保證只有一個「精子」能獲得「卵子」的寵幸，當有一個精子進入后，卵子的外殼就會發(fā)生變化，將通道關閉把其余的精子阻擋在外。

億級別的精子就好比「并發(fā)」流量;

卵子就好比是共享資源;

卵子外殼只允許一個精子進入的特殊蛋白就是一把鎖。

而多節(jié)點構成的集群，就會有多個 JVM 進程，我們獲得同樣的效果就需要有一個中間人協(xié)調(diào)，只允許一個 JVM 中的一個線程獲得操作共享資源的資格。

分布式鎖就是用來控制同一時刻，只有一個 JVM 進程中的一個線程「精子」可以訪問被保護的資源「卵子」。

「每一個生命，都是億級選手中的佼佼者」，加油。

分布式鎖入門

分布式鎖應該滿足哪些特性?

• 互斥：在任何給定時刻，只有一個客戶端可以持有鎖;
• 無死鎖：任何時刻都有可能獲得鎖，即使獲取鎖的客戶端崩潰;
• 容錯：只要大多數(shù) Redis的節(jié)點都已經(jīng)啟動，客戶端就可以獲取和釋放鎖。

碼哥，我可以使用 SETNX key value 命令是實現(xiàn)「互斥」特性。

這個命令來自于SET if Not eXists的縮寫，意思是：如果 key 不存在，則設置 value 給這個key，否則啥都不做。

命令的返回值：

• 1：設置成功;
• 0：key 沒有設置成功。

如下場景：

敲代碼一天累了，想去放松按摩下肩頸。

168 號技師最搶手，大家喜歡點，所以并發(fā)量大，需要分布式鎖控制。

同一時刻只允許一個「客戶」預約 168 技師。

肖彩機申請 168 技師成功：

> SETNX lock:168 1 
 
(integer) 1 # 獲取 168 技師成功 

謝霸哥后面到，申請失敗：

> SETNX lock 2 
 
(integer) 0 # 客戶謝霸哥 2 獲取失敗 

此刻，申請成功的客戶就可以享受 168 技師的肩頸放松服務「共享資源」。

享受結(jié)束后，要及時釋放鎖，給后來者享受 168 技師的服務機會。

肖彩機，碼哥考考你如何釋放鎖呢?

很簡單，使用 DEL 刪除這個 key 就行。

> DEL lock:168 
 
(integer) 1 

碼哥，你見過「龍」么?我見過，因為我被一條龍服務過。

肖彩機，事情可沒這么簡單。

這個方案存在一個存在造成「死鎖」的問題，造成該問題的場景如下：

在按摩過程中突然收到線上報警，提起褲子就跑去公司了，沒及時執(zhí)行 DEL 釋放鎖(客戶端處理業(yè)務異常，無法正確釋放鎖);

按摩過程中心肌梗塞嗝屁了，無法執(zhí)行 DEL指令。

這樣，這個鎖就會一直占用，其他客戶就「再也沒有」機會獲取 168 技師服務了。

如何避免死鎖

碼哥，我可以在獲取鎖成功的時候設置一個「超時時間」

比如設定按摩服務一次 60 分鐘，那么在給這個 key 加鎖的時候設置 60 分鐘過期即可：

> SETNX lock:168 1  // 獲取鎖 
(integer) 1 
> EXPIRE lock:168 60  // 60s 自動刪除 
(integer) 1 

這樣，到點后鎖自動釋放，其他客戶就可以繼續(xù)享受 168 技師按摩服務了。

誰要這么寫，就糟透了。

「加鎖」、「設置超時」是兩個命令，他們不是原子操作。

如果出現(xiàn)只執(zhí)行了第一條，第二條沒機會執(zhí)行就會出現(xiàn)「超時時間」設置失敗，依然出現(xiàn)死鎖。

比如以下場景導致無法執(zhí)行第二條指令：

Redis 異常宕機;

客戶端異常崩潰;

碼哥，那咋辦，我想被一條龍服務，不能出現(xiàn)死鎖啊。

Redis 2.6.12 之后，拓展了 SET 命令的參數(shù)，滿足了當 key 不存在則設置 value，同時設置超時時間的語義，并且滿足原子性。

SET resource_name random_value NX PX 30000 

NX：表示只有 resource_name 不存在的時候才能 SET 成功，從而保證只有一個客戶端可以獲得鎖;

PX 30000：表示這個鎖有一個 30 秒自動過期時間。

執(zhí)行時間超過鎖的過期時間

這樣我能穩(wěn)妥的享受一條龍服務了么?

No，還有一種場景會導致釋放別人的鎖：

• 客戶 1 獲取鎖成功并設置 30 秒超時;
• 客戶 1 因為一些原因?qū)е聢?zhí)行很慢(網(wǎng)絡問題、發(fā)生 FullGC……)，過了 30 秒依然沒執(zhí)行完，但是鎖過期「自動釋放了」;
• 客戶 2 申請加鎖成功;
• 客戶 1 執(zhí)行完成，執(zhí)行 DEL 釋放鎖指令，這個時候就把 客戶 2 的鎖給釋放了。

有兩個關鍵問題需要解決：

• 如何合理設置過期時間?
• 如何避免刪除別人持有的鎖。

正確設置鎖超時

鎖的超時時間怎么計算合適呢?

這個時間不能瞎寫，一般要根據(jù)在測試環(huán)境多次測試，然后壓測多輪之后，比如計算出平均執(zhí)行時間 200 ms。

那么鎖的超時時間就放大為平均執(zhí)行時間的 3~5 倍。

為啥要放大呢?

因為如果鎖的操作邏輯中有網(wǎng)絡 IO 操作、JVM FullGC 等，線上的網(wǎng)絡不會總一帆風順，我們要給網(wǎng)絡抖動留有緩沖時間。

那我設置更大一點，比如設置 1 小時不是更安全?

不要鉆牛角，多大算大?

設置時間過長，一旦發(fā)生宕機重啟，就意味著 1 小時內(nèi)，分布式鎖的服務全部節(jié)點不可用。

你要讓運維手動刪除這個鎖么?

只要運維真的不會打你。

有沒有完美的方案呢?不管時間怎么設置都不大合適。

我們可以讓獲得鎖的線程開啟一個守護線程，用來給快要過期的鎖「續(xù)航」。

加鎖的時候設置一個過期時間，同時客戶端開啟一個「守護線程」，定時去檢測這個鎖的失效時間。

如果快要過期，但是業(yè)務邏輯還沒執(zhí)行完成，自動對這個鎖進行續(xù)期，重新設置過期時間。

這個道理行得通，可我寫不出。

別慌，已經(jīng)有一個庫把這些工作都封裝好了他叫Redisson。

Redisson 是一個 Java 語言實現(xiàn)的 Redis SDK 客戶端，在使用分布式鎖時，它就采用了「自動續(xù)期」的方案來避免鎖過期，這個守護線程我們一般也把它叫做「看門狗」線程。

關于 Redisson 的使用與原理分析由于篇幅有限，大家可關注「碼哥字節(jié)」且聽下回分解。

避免釋放別人的鎖

出現(xiàn)釋放別人鎖的關鍵在于「無腦執(zhí)行」DEL指令，所以我們要想辦法檢查下這個鎖是不是自己加的。

解鈴還須系鈴人

碼哥，我在加鎖的時候設置一個「唯一標識」作為 value 代表加鎖的客戶端。

在釋放鎖的時候，客戶端將自己的「唯一標識」與鎖上的「標識」比較是否相等，匹配上則刪除，否則沒有權利釋放鎖。

偽代碼如下：

// 比對 value 與 唯一標識 
if (redis.get("lock:168").equals(uuid)){ 
   redis.del("lock:168"); //比對成功則刪除 
 } 

有沒有想過，這是 GET + DEL 指令組合而成的，這里又會涉及到原子性問題。

復現(xiàn)下情況：

• 客戶端 1 第一步對比成功后，第二步還沒來得及執(zhí)行，這時候鎖到期了。
• 客戶端 2 獲取鎖成功，將自己的 「uuid」設置進去。
• 這時候客戶端 1 執(zhí)行第二步進行釋放鎖，這肯定是錯誤的。

我們是追求極致的男人，所以這里通過 Lua 腳本來實現(xiàn)，這樣判斷和刪除的過程就是原子操作了。

if redis.call("get",KEYS[1]) == ARGV[1] then 
    return redis.call("del",KEYS[1]) 
else 
    return 0 
end 

一路優(yōu)化下來，方案似乎比較「嚴謹」了，抽象出對應的模型如下。

通過 SET lock_resource_name $unique_id NX PX $expire_time，同時啟動守護線程為快要過期單還沒執(zhí)行完畢的客戶端的鎖續(xù)命;

客戶端執(zhí)行業(yè)務邏輯操作共享資源;

通過 Lua 腳本釋放鎖，先 get 判斷鎖是否是自己加的，再執(zhí)行 DEL。

加解鎖代碼位置有講究

根據(jù)前面的分析，我們已經(jīng)有了一個「相對嚴謹」的分布式鎖了。

于是「謝霸哥」就寫了如下代碼將分布式鎖運用到項目中，以下是偽代碼邏輯：

public void doSomething() { 
    try { 
        redisLock.lock(); // 上鎖 
        // 處理業(yè)務 
        redisLock.unlock(); // 釋放鎖 
    } catch (Exception e) { 
        e.printStackTrace(); 
    } 
} 

一旦執(zhí)行業(yè)務邏輯過程中拋出異常，程序就無法走下一步釋放鎖的流程。

所以釋放鎖的代碼一定要放在 finally{} 塊中。

加鎖的位置也有問題，如果執(zhí)行 redisLock.lock() 加鎖異常，那么就會執(zhí)行 finally{} 代碼塊指令執(zhí)行解鎖，這個時候鎖并沒有申請成功。

所以 redisLock.lock();應該放在 try 外面。

綜上所述，正確代碼位置如下 ：

public void doSomething() { 
   // 上鎖 
   redisLock.lock(); 
    try { 
        // 處理業(yè)務 
        ... 
    } catch (Exception e) { 
        e.printStackTrace(); 
    } finally { 
      // 釋放鎖 
      redisLock.unlock(); 
    } 
} 

實現(xiàn)可重入鎖

可重入鎖要如何實現(xiàn)呢?重入之后，超時時間如何設置呢?

當一個線程執(zhí)行一段代碼成功獲取鎖之后，繼續(xù)執(zhí)行時，又遇到加鎖的代碼，可重入性就就保證線程能繼續(xù)執(zhí)行，而不可重入就是需要等待鎖釋放之后，再次獲取鎖成功，才能繼續(xù)往下執(zhí)行。

用一段代碼解釋可重入：

public synchronized void a() { 
    b(); 
} 
public synchronized void b() { 
    // pass 
} 

假設 X 線程在 a 方法獲取鎖之后，繼續(xù)執(zhí)行 b 方法，如果此時不可重入，線程就必須等待鎖釋放，再次爭搶鎖。

鎖明明是被 X 線程擁有，卻還需要等待自己釋放鎖，然后再去搶鎖，這看起來就很奇怪，我釋放我自己~

Redis Hash 可重入鎖

Redisson 類庫就是通過 Redis Hash 來實現(xiàn)可重入鎖，未來碼哥會專門寫一篇關于 Redisson 的使用與原理的文章……

當線程擁有鎖之后，往后再遇到加鎖方法，直接將加鎖次數(shù)加 1，然后再執(zhí)行方法邏輯。

退出加鎖方法之后，加鎖次數(shù)再減 1，當加鎖次數(shù)為 0 時，鎖才被真正的釋放。

可以看到可重入鎖最大特性就是計數(shù)，計算加鎖的次數(shù)。

所以當可重入鎖需要在分布式環(huán)境實現(xiàn)時，我們也就需要統(tǒng)計加鎖次數(shù)。

加鎖邏輯

我們可以使用 Redis hash 結(jié)構實現(xiàn)，key 表示被鎖的共享資源， hash 結(jié)構的 fieldKey 的 value 則保存加鎖的次數(shù)。

通過 Lua 腳本實現(xiàn)原子性，假設 KEYS1 = 「lock」, ARGV「1000，uuid」：

---- 1 代表 true 
---- 0 代表 false 
 
if (redis.call('exists', KEYS[1]) == 0) then 
    redis.call('hincrby', KEYS[1], ARGV[2], 1); 
    redis.call('pexpire', KEYS[1], ARGV[1]); 
    return 1; 
end ; 
if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then 
    redis.call('hincrby', KEYS[1], ARGV[2], 1); 
    redis.call('pexpire', KEYS[1], ARGV[1]); 
    return 1; 
end ; 
return 0; 

加鎖代碼首先使用 Redis exists 命令判斷當前 lock 這個鎖是否存在。

如果鎖不存在的話，直接使用 hincrby創(chuàng)建一個鍵為 lock hash 表，并且為 Hash 表中鍵為 uuid 初始化為 0，然后再次加 1，最后再設置過期時間。

如果當前鎖存在，則使用 hexists判斷當前 lock 對應的 hash 表中是否存在 uuid 這個鍵，如果存在，再次使用 hincrby 加 1，最后再次設置過期時間。

最后如果上述兩個邏輯都不符合，直接返回。

解鎖邏輯

-- 判斷 hash set 可重入 key 的值是否等于 0 
-- 如果為 0 代表 該可重入 key 不存在 
if (redis.call('hexists', KEYS[1], ARGV[1]) == 0) then 
    return nil; 
end ; 
-- 計算當前可重入次數(shù) 
local counter = redis.call('hincrby', KEYS[1], ARGV[1], -1); 
-- 小于等于 0 代表可以解鎖 
if (counter > 0) then 
    return 0; 
else 
    redis.call('del', KEYS[1]); 
    return 1; 
end ; 
return nil; 

首先使用 hexists 判斷 Redis Hash 表是否存給定的域。

如果 lock 對應 Hash 表不存在，或者 Hash 表不存在 uuid 這個 key，直接返回 nil。

若存在的情況下，代表當前鎖被其持有，首先使用 hincrby使可重入次數(shù)減 1 ，然后判斷計算之后可重入次數(shù)，若小于等于 0，則使用 del 刪除這把鎖。

解鎖代碼執(zhí)行方式與加鎖類似，只不過解鎖的執(zhí)行結(jié)果返回類型使用 Long。這里之所以沒有跟加鎖一樣使用 Boolean ,這是因為解鎖 lua 腳本中，三個返回值含義如下：

• 1 代表解鎖成功，鎖被釋放
• 0 代表可重入次數(shù)被減 1
• null 代表其他線程嘗試解鎖，解鎖失敗

主從架構帶來的問題

碼哥，到這里分布式鎖「很完美了」吧，沒想到分布式鎖這么多門道。

路還很遠，之前分析的場景都是，鎖在「單個」Redis 實例中可能產(chǎn)生的問題，并沒有涉及到 Redis 的部署架構細節(jié)。

我們通常使用「Cluster 集群」或者「哨兵集群」的模式部署保證高可用。

這兩個模式都是基于「主從架構數(shù)據(jù)同步復制」實現(xiàn)的數(shù)據(jù)同步，而 Redis 的主從復制默認是異步的。

我們試想下如下場景會發(fā)生什么問題：

如果客戶端 1 剛往 master 節(jié)點寫入一個分布式鎖，此時這個指令還沒來得及同步到 slave 節(jié)點。

此時，master 節(jié)點宕機，其中一個 slave 被選舉為新 master，這時候新 master 是沒有客戶端 1 寫入的鎖，鎖丟失了。

此刻，客戶端 2 線程來獲取鎖，就成功了。

雖然這個概率極低，但是我們必須得承認這個風險的存在。

Redis 的作者提出了一種解決方案，叫 Redlock(紅鎖)

Redis 的作者為了統(tǒng)一分布式鎖的標準，搞了一個 Redlock，算是 Redis 官方對于實現(xiàn)分布式鎖的指導規(guī)范，https://redis.io/topics/distlock，但是這個 Redlock 也被國外的一些分布式專家給噴了。

因為它也不完美，有“漏洞”。

什么是 Redlock

紅鎖是不是這個?

泡面吃多了你，Redlock 紅鎖是為了解決主從架構中鎖丟失而提出的一種算法。

Redlock 的方案基于 2 個前提：

• 不需要部署從庫和哨兵實例，只部署主庫
• 但主庫要部署多個，官方推薦至少 5 個實例，這樣可以保證他們不會同時宕機。

也就是說，想用使用 Redlock，你至少要部署 5 個 Redis 實例，而且都是主庫，它們之間沒有任何關系，都是一個個孤立的實例。

一個客戶端要獲取鎖有 5 個步驟：

• 客戶端獲取當前時間 T1(毫秒級別);
• 使用相同的 key和 value順序嘗試從 N個 Redis實例上獲取鎖。
  • 每個請求都設置一個超時時間(毫秒級別)，該超時時間要遠小于鎖的有效時間，這樣便于快速嘗試與下一個實例發(fā)送請求。
  • 比如鎖的自動釋放時間 10s，則請求的超時時間可以設置 5~50 毫秒內(nèi)，這樣可以防止客戶端長時間阻塞。
• 客戶端獲取當前時間 T2 并減去步驟 1 的 T1 來計算出獲取鎖所用的時間(T3 = T2 -T1)。當且僅當客戶端在大多數(shù)實例(N/2 + 1)獲取成功，且獲取鎖所用的總時間 T3 小于鎖的有效時間，才認為加鎖成功，否則加鎖失敗。
• 如果第 3 步加鎖成功，則執(zhí)行業(yè)務邏輯操作共享資源，key 的真正有效時間等于有效時間減去獲取鎖所使用的時間(步驟 3 計算的結(jié)果)。
• 如果因為某些原因，獲取鎖失敗(沒有在至少 N/2+1 個 Redis 實例取到鎖或者取鎖時間已經(jīng)超過了有效時間)，客戶端應該在所有的 Redis 實例上進行解鎖(即便某些 Redis 實例根本就沒有加鎖成功)。

為什么要部署多個實例并加鎖呢?

本質(zhì)是為了高可用和容錯，即使部分實例宕機，大多數(shù)實例加鎖成功，整個分布式鎖服務依然可用。

為啥在第三步要計算加鎖的累計時間?

因為多個節(jié)點加鎖，耗時可能會比較長，網(wǎng)絡中可能存在丟包、超時等現(xiàn)象。

即使大多數(shù)節(jié)點獲取鎖成功，假如獲取鎖的總時間已經(jīng)超過鎖的有效時間，這個鎖已經(jīng)沒有意義了。

為什么釋放鎖要操作所有節(jié)點，即使有的節(jié)點加鎖未成功?

因為有可能客戶端在 Redis 實例上加鎖成功，只是客戶端讀取響應的時候失敗導致客戶端以為加鎖失敗。

為了安全的清理鎖，就需要向每個節(jié)點發(fā)送釋放鎖的請求。

Redlock 這么完美?那他解決了 Redis 主從架構節(jié)點異常宕機導致鎖丟失的問題了么?

事情可沒這么簡單，Redis 作者把這個方案提出后，受到了業(yè)界著名的分布式系統(tǒng)專家的質(zhì)疑。

兩人好比神仙打架，兩人一來一回論據(jù)充足的對一個問題提出很多論斷……

由于篇幅原因，關于 兩人的爭論分析以及 Redssion 對分布式鎖的封裝以及 Redlock 的實現(xiàn)我們下期再見。

預知后事如何，且聽下回分解…

總結(jié)

完工，我建議你合上屏幕，自己在腦子里重新過一遍，每一步都在做什么，為什么要做，解決什么問題。

我們一起從頭到尾梳理了一遍 Redis 分布式鎖中的各種門道，其實很多點是不管用什么做分布式鎖都會存在的問題，重要的是思考的過程。

對于系統(tǒng)的設計，每個人的出發(fā)點都不一樣，沒有完美的架構，沒有普適的架構，但是在完美和普適能平衡的很好的架構，就是好的架構。

關于 Redlock 的爭論主要集中在如下幾點：

• Redlock 效率太差、太重，對于提升效率的場景下，使用分布式鎖，允許鎖的偶爾失效，那么使用單 Redis 節(jié)點的鎖方案就足夠了，簡單而且效率高。
• 對于正確性要求高的場景下，它是依賴于時間的，不是一個足夠強的算法。Redlock 并沒有保住正確性。