面試題詳解：用Redis實(shí)現(xiàn)分布式鎖的血淚史
在知識(shí)星球上有人問：
使用Redis分布式鎖的詳細(xì)方案是什么？
一個(gè)很簡(jiǎn)單的答案就是去使用 Redission 客戶端。Redission 中的鎖方案就是 Redis 分布式鎖的比較完美的詳細(xì)方案。
那么，Redission 中的鎖方案為什么會(huì)比較完美呢？
正好，我用 Redis 做分布式鎖經(jīng)驗(yàn)十分豐富，在實(shí)際工作中，也探索過許多種使用 Redis 做分布式鎖的方案，經(jīng)過了無(wú)數(shù)血淚教訓(xùn)。
所以，在談及 Redission 鎖為什么比較完美之前，先給大家看看我曾經(jīng)使用 Redis 做分布式鎖遇到過的問題。
我曾經(jīng)用 Redis 做分布式鎖想去解決一個(gè)用戶搶優(yōu)惠券的問題。這個(gè)業(yè)務(wù)需求是這樣的：當(dāng)用戶領(lǐng)完一張優(yōu)惠券后，優(yōu)惠券的數(shù)量必須相應(yīng)減一，如果優(yōu)惠券搶光了，就不允許用戶再搶了。
在實(shí)現(xiàn)時(shí)，先從數(shù)據(jù)庫(kù)中先讀出優(yōu)惠券的數(shù)量進(jìn)行判斷，當(dāng)優(yōu)惠券大于 0，就進(jìn)行允許領(lǐng)取優(yōu)惠券，然后，再將優(yōu)惠券數(shù)量減一后，寫回?cái)?shù)據(jù)庫(kù)。
當(dāng)時(shí)由于請(qǐng)求數(shù)量比較多，所以，我們使用了三臺(tái)服務(wù)器去做分流。
這時(shí)候會(huì)出現(xiàn)一個(gè)問題：
如果其中一臺(tái)服務(wù)器上的 A 應(yīng)用獲取到了優(yōu)惠券的數(shù)量之后，由于處理相關(guān)業(yè)務(wù)邏輯，未及時(shí)更新數(shù)據(jù)庫(kù)的優(yōu)惠券數(shù)量；在 A 應(yīng)用處理業(yè)務(wù)邏輯的時(shí)候，另一臺(tái)服務(wù)器上的 B 應(yīng)用更新了優(yōu)惠券數(shù)量。那么，等 A 應(yīng)用去更新數(shù)據(jù)庫(kù)中優(yōu)惠券數(shù)量時(shí)，就會(huì)把 B 應(yīng)用更新的優(yōu)惠券數(shù)量覆蓋掉。
看到這里，可能有人比較奇怪，為什么這里不直接使用 SQL：
update?優(yōu)惠券表?set?優(yōu)惠券數(shù)量?=?優(yōu)惠券數(shù)量?-?1?where?優(yōu)惠券id?=?xxx
原因是這樣做，在沒有分布式鎖協(xié)調(diào)下，優(yōu)惠券數(shù)量可能直接會(huì)出現(xiàn)負(fù)數(shù)。因?yàn)楫?dāng)優(yōu)惠券數(shù)量為 1 的時(shí)候，如果兩個(gè)用戶通過兩臺(tái)服務(wù)器同時(shí)發(fā)起搶優(yōu)惠券的請(qǐng)求，都滿足優(yōu)惠券大于 0 的條件，然后都執(zhí)行這條 SQL 語(yǔ)句，結(jié)果優(yōu)惠券數(shù)量直接變成 -1 了。
還有人說可以用樂觀鎖，比如使用如下 SQL:
update?優(yōu)惠券表?set?優(yōu)惠券數(shù)量?=?優(yōu)惠券數(shù)量?-?1?where?優(yōu)惠券id?=?xxx?and?version?=?xx
這種方式就在一定幾率下，很可能出現(xiàn)數(shù)據(jù)一直更新不上，導(dǎo)致長(zhǎng)時(shí)間重試的情況。
所以，經(jīng)過綜合考慮，我們就采用了 Redis 分布式鎖，通過互斥的方式，以防止多個(gè)客戶端去同時(shí)更新優(yōu)惠券數(shù)量的方案。
當(dāng)時(shí)，我們首先想到的就是使用 Redis 的 setnx 命令，setnx 命令其實(shí)就是 set if not exists 的簡(jiǎn)寫。
當(dāng) key 設(shè)置值成功后，則返回 1，否則就返回 0。所以，這里 setnx 設(shè)置成功可以表示成獲取到鎖，如果失敗，則說明已經(jīng)有鎖，可以被視作獲取鎖失敗。
setnx?lock?true
如果想要釋放鎖，執(zhí)行 del 指令，把 key 刪除即可。
del?lock
利用這個(gè)特性，我們就可以讓系統(tǒng)在執(zhí)行優(yōu)惠券邏輯之前，先去 Redis 中執(zhí)行 setnx 指令。再根據(jù)指令執(zhí)行結(jié)果，去判斷是否獲取到鎖。如果獲取到了，就繼續(xù)執(zhí)行業(yè)務(wù)，執(zhí)行完再使用 del 指令去釋放鎖。如果沒有獲取到，就等待一定時(shí)間，重新再去獲取鎖。
乍一看，這一切沒什么問題，使用 setnx 指令確實(shí)起到了想要的互斥效果。
但是，這是建立在所有運(yùn)行環(huán)境都是正常的情況下的。一旦運(yùn)行環(huán)境出現(xiàn)了異常，問題就出現(xiàn)了。
想一下，持有鎖的應(yīng)用突然崩潰了，或者所在的服務(wù)器宕機(jī)了，會(huì)出現(xiàn)什么情況？
這會(huì)造成死鎖——持有鎖的應(yīng)用無(wú)法釋放鎖，其他應(yīng)用根本也沒有機(jī)會(huì)再去獲取鎖了。這會(huì)造成巨大的線上事故，我們要改進(jìn)方案，解決這個(gè)問題。
怎么解決呢？咱們可以看到，造成死鎖的根源是，一旦持有鎖的應(yīng)用出現(xiàn)問題，就不會(huì)去釋放鎖。從這個(gè)方向思考，可以在 Redis 上給 key 一個(gè)過期時(shí)間。
這樣的話，即使出現(xiàn)問題，key 也會(huì)在一段時(shí)間后釋放，是不是就解決了這個(gè)問題呢？實(shí)際上，大家也確實(shí)是這么做的。
不過，由于 setnx 這個(gè)指令本身無(wú)法設(shè)置超時(shí)時(shí)間，所以一般會(huì)采用兩種辦法來(lái)做這件事：
1、采用 lua 腳本，在使用 setnx 指令之后，再使用 expire 命令去給 key 設(shè)置過期時(shí)間。
if?redis.call("SETNX",?"lock",?"true")?==?1?then
??local?expireResult?=?redis.call("expire",?"lock",?"10")
??if?expireResult?==?1?then
??????return?"success"
??else
??????return?"expire?failed"
??end
else
??return?"setnx?not?null"
end
2、直接使用 set(key,value,NX,EX,timeout) 指令，同時(shí)設(shè)置鎖和超時(shí)時(shí)間。
redis.call("SET",?"lock",?"true",?"NX",?"PX",?"10000")
以上兩種方法，使用哪種方式都可以。
釋放鎖的腳本兩種方式都一樣，直接調(diào)用 Redis 的 del 指令即可。
到目前為止，我們的鎖既起到了互斥效果，又不會(huì)因?yàn)槟承┏钟墟i的系統(tǒng)出現(xiàn)問題，導(dǎo)致死鎖了。這樣就完美了嗎？
假設(shè)有這樣一種情況，如果一個(gè)持有鎖的應(yīng)用，其持有的時(shí)間超過了我們?cè)O(shè)定的超時(shí)時(shí)間會(huì)怎樣呢？會(huì)出現(xiàn)兩種情況：
發(fā)現(xiàn)系統(tǒng)在 Redis 中設(shè)置的 key 還存在 發(fā)現(xiàn)系統(tǒng)在 Redis 中設(shè)置的 key 不存在
出現(xiàn)第一種情況比較正常。因?yàn)槟惝吘箞?zhí)行任務(wù)超時(shí)了，key 被正常清除也是符合邏輯的。
但是最可怕的是第二種情況，發(fā)現(xiàn)設(shè)置的 key 還存在。這說明什么？說明當(dāng)前存在的 key，是另外的應(yīng)用設(shè)置的。
這時(shí)候如果持有鎖超時(shí)的應(yīng)用調(diào)用 del 指令去刪除鎖時(shí)，就會(huì)把別人設(shè)置的鎖誤刪除，這會(huì)直接導(dǎo)致系統(tǒng)業(yè)務(wù)出現(xiàn)問題。
所以，為了解決這個(gè)問題，我們需要繼續(xù)對(duì) Redis 腳本進(jìn)行改動(dòng)……毀滅吧，累了……
首先，我們要讓應(yīng)用在獲取鎖的時(shí)候，去設(shè)置一個(gè)只有應(yīng)用自己知道的獨(dú)一無(wú)二的值。
通過這個(gè)唯一值，系統(tǒng)在釋放鎖的時(shí)候，就能識(shí)別出這鎖是不是自己設(shè)置的。如果是自己設(shè)置的，就釋放鎖，也就是刪除 key；如果不是，則什么都不做。
腳本如下：
if?redis.call("SETNX",?"lock",?ARGV[1])?==?1?then
?local?expireResult?=?redis.call("expire",?"lock",?"10")
?if?expireResult?==?1?then
?????return?"success"
?else
?????return?"expire?failed"
?end
else
??return?"setnx?not?null"
end
或者
redis.call("SET",?"lock",?ARGV[1],?"NX",?"PX",?"10000")
這里，ARGV[1] 是一個(gè)可傳入的參數(shù)變量，可以傳入唯一值。比如一個(gè)只有自己知道的 UUID 的值，或者通過雪球算法，生成只有自己持有的唯一 ID。
釋放鎖的腳本改成這樣：
if?redis.call("get",?"lock")?==?ARGV[1]?
??then?
?????return?redis.call("del",?"lock")?
??else?
?????return?0?
end
可以看到，從業(yè)務(wù)角度，無(wú)論如何，我們的分布式鎖已經(jīng)可以滿足真正的業(yè)務(wù)需求了。能互斥，不死鎖，不會(huì)誤刪除別人的鎖，只有自己上的鎖，自己可以釋放。
一切都是那么美好！！！
可惜，還有個(gè)隱患，我們并未排除。這個(gè)隱患就是 Redis 自身。
要知道，lua 腳本都是用在 Redis 的單例上的。一旦 Redis 本身出現(xiàn)了問題，我們的分布式鎖就沒法用了，分布式鎖沒法用，對(duì)業(yè)務(wù)的正常運(yùn)行會(huì)造成重大影響，這是我們無(wú)法接受的。
所以，我們需要把 Redis 搞成高可用的。一般來(lái)講，解決 Redis 高可用的問題，都是使用主從集群。
但是搞主從集群，又會(huì)引入新的問題。主要問題在于，Redis 的主從數(shù)據(jù)同步有延遲。這種延遲會(huì)產(chǎn)生一個(gè)邊界條件：當(dāng)主機(jī)上的 Redis 已經(jīng)被人建好了鎖，但是鎖數(shù)據(jù)還未同步到從機(jī)時(shí)，主機(jī)宕了。隨后，從機(jī)提升為主機(jī)，此時(shí)從機(jī)上是沒有以前主機(jī)設(shè)置好的鎖數(shù)據(jù)的——鎖丟了……丟了……了……
到這里，終于可以介紹 Redission（開源 Redis 客戶端）了，我們來(lái)看看它怎么是實(shí)現(xiàn) Redis 分布式鎖的。
Redission 實(shí)現(xiàn)分布式鎖的思想很簡(jiǎn)單，無(wú)論是主從集群還是 Redis Cluster 集群，它會(huì)對(duì)集群中的每個(gè) Redis，挨個(gè)去執(zhí)行設(shè)置 Redis 鎖的腳本，也就是集群中的每個(gè) Redis 都會(huì)包含設(shè)置好的鎖數(shù)據(jù)。
我們通過一個(gè)例子來(lái)介紹一下。
假設(shè) Redis 集群有 5 臺(tái)機(jī)器，同時(shí)根據(jù)評(píng)估，鎖的超時(shí)時(shí)間設(shè)置成 10 秒比較合適。
第 1 步，咱們先算出集群總的等待時(shí)間，集群總的等待時(shí)間是 5 秒（鎖的超時(shí)時(shí)間 10 秒 / 2）。
第 2 步，用 5 秒除以 5 臺(tái)機(jī)器數(shù)量，結(jié)果是 1 秒。這個(gè) 1 秒是連接每臺(tái) Redis 可接受的等待時(shí)間。
第 3 步，依次連接 5 臺(tái) Redis，并執(zhí)行 lua 腳本設(shè)置鎖，然后再做判斷：
如果在 5 秒之內(nèi)，5 臺(tái)機(jī)器都有執(zhí)行結(jié)果，并且半數(shù)以上（也就是 3 臺(tái)）機(jī)器設(shè)置鎖成功，則認(rèn)為設(shè)置鎖成功；少于半數(shù)機(jī)器設(shè)置鎖成功，則認(rèn)為失敗。 如果超過 5 秒，不管幾臺(tái)機(jī)器設(shè)置鎖成功，都認(rèn)為設(shè)置鎖失敗。比如，前 4 臺(tái)設(shè)置成功一共花了 3 秒，但是最后 1 臺(tái)機(jī)器用了 2 秒也沒結(jié)果，總的等待時(shí)間已經(jīng)超過了 5 秒，即使半數(shù)以上成功，這也算作失敗。
再額外多說一句，在很多業(yè)務(wù)邏輯里，其實(shí)對(duì)鎖的超時(shí)時(shí)間是沒有需求的。
比如，凌晨批量執(zhí)行處理的任務(wù)，可能需要分布式鎖保證任務(wù)不會(huì)被重復(fù)執(zhí)行。此時(shí)，任務(wù)要執(zhí)行多長(zhǎng)時(shí)間是不明確的。如果設(shè)置分布式鎖的超時(shí)時(shí)間在這里，并沒有太大意義。但是，不設(shè)置超時(shí)時(shí)間，又會(huì)引發(fā)死鎖問題。
所以，解決這種問題的通用辦法是，每個(gè)持有鎖的客戶端都啟動(dòng)一個(gè)后臺(tái)線程，通過執(zhí)行特定的 lua 腳本，去不斷地刷新 Redis 中的 key 超時(shí)時(shí)間，使得在任務(wù)執(zhí)行完成前，key 不會(huì)被清除掉。
腳本如下：
if?redis.call("get",?"lock")?==?ARGV[1]?
??then?
????return?redis.call("expire",?"lock",?"10")
?else?
????return?0?
end
其中，ARGV[1] 是可傳入的參數(shù)變量，表示持有鎖的系統(tǒng)的唯一值，也就是只有持有鎖的客戶端才能刷新 key 的超時(shí)時(shí)間。
到此為止，一個(gè)完整的分布式鎖才算實(shí)現(xiàn)完畢。總結(jié)實(shí)現(xiàn)方案如下：
使用 set 命令設(shè)置鎖標(biāo)記，必須有超時(shí)時(shí)間，以便客戶端崩潰，也可以釋放鎖； 對(duì)于不需要超時(shí)時(shí)間的，需要自己實(shí)現(xiàn)一個(gè)能不斷刷新鎖超時(shí)時(shí)間的線程； 每個(gè)獲取鎖的客戶端，在 Redis 中設(shè)置的 value 必須是獨(dú)一無(wú)二的，以便識(shí)別出是由哪個(gè)客戶端設(shè)置的鎖； 分布式集群中，直接每臺(tái)機(jī)器設(shè)置一樣的超時(shí)時(shí)間和鎖標(biāo)記； 為了保證集群設(shè)置的鎖不會(huì)因?yàn)榫W(wǎng)絡(luò)問題導(dǎo)致某些已經(jīng)設(shè)置的鎖出現(xiàn)超時(shí)的情況，必須合理設(shè)置網(wǎng)絡(luò)等待時(shí)間和鎖超時(shí)時(shí)間。
這個(gè)分布式鎖滿足如下四個(gè)條件：
任意時(shí)刻只能有一個(gè)客戶端持有鎖； 不能發(fā)生死鎖，有一個(gè)客戶端持有鎖期間出現(xiàn)了問題沒有解鎖，也能保證后面別的客戶端繼續(xù)去持有鎖； 加鎖和解鎖必須是同一個(gè)客戶端，客戶端自己加的鎖只能自己去解； 只要大多數(shù) Redis 節(jié)點(diǎn)正常，客戶端就能正常使用鎖。
當(dāng)然，在 Redission 中的腳本，為了保證鎖的可重入，又對(duì) lua 腳本做了一定的修改，現(xiàn)在把完整的 lua 腳本貼在下面。
獲取鎖的 lua 腳本：
if?(redis.call('exists',?KEYS[1])?==?0)?then
??redis.call('hincrby',?KEYS[1],?ARGV[2],?1);
??redis.call('pexpire',?KEYS[1],?ARGV[1]);
??return?nil;
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?nil;
end;
return?redis.call('pttl',?KEYS[1]);
對(duì)應(yīng)的刷新鎖超時(shí)時(shí)間的腳本：
if?(redis.call('hexists',?KEYS[1],?ARGV[2])?==?1)?then?
?redis.call('pexpire',?KEYS[1],?ARGV[1]);?
??return?1;?
end;??
return?0;
對(duì)應(yīng)的釋放鎖的腳本：
if?(redis.call('hexists',?KEYS[1],?ARGV[3])?==?0)?then
?return?nil;
end;
local?counter?=?redis.call('hincrby',?KEYS[1],?ARGV[3],?-1);?
if?(counter?>?0)?then
?redis.call('pexpire',?KEYS[1],?ARGV[2]);
return?0;
else
?redis.call('del',?KEYS[1]);
?redis.call('publish',?KEYS[2],?ARGV[1]);
return?1;
end;
return?nil;
到現(xiàn)在為止，使用 Redis 作為分布式鎖的詳細(xì)方案就寫完了。
我既寫了一步一坑的坎坷經(jīng)歷，也寫明了各個(gè)問題和解決問題的細(xì)節(jié)，希望大家看完能有所收獲。
最后再給大家提個(gè)醒，使用 Redis 集群做分布式鎖，有一定的爭(zhēng)議性，還需要大家在實(shí)際用的時(shí)候，根據(jù)現(xiàn)實(shí)情況，做出更好的選擇和取舍。
你好，我是四猿外。
我原創(chuàng)了不少文章，把其中的一些精華文章做了個(gè)匯總整理，搞了一份PDF——《爬坡》，其中包括了15篇技術(shù)文章（學(xué)習(xí)編程技巧、架構(gòu)師、MQ、分布式）和 13 篇非技術(shù)文章（主要是程序員職場(chǎng)）。
這份文檔的質(zhì)量咋樣？我就不多自吹了，很多人看完說”受益匪淺“。
想獲取《爬坡》，可以關(guān)注我的公眾號(hào)「四猿外」，在后臺(tái)回復(fù)：爬坡
另外，我建了一個(gè)讀者交流群，里面大部分是程序員，一起聊技術(shù)、工作、八卦。歡迎加我微信（備注加群），拉你入群。
推薦閱讀