面試題詳解：用Redis實(shí)現(xiàn)分布式鎖的血淚史

ZhouAndrew 2022-03-13

展開(kāi)全文

在知識(shí)星球上有人問(wèn)：

使用Redis分布式鎖的詳細(xì)方案是什么,？

一個(gè)很簡(jiǎn)單的答案就是去使用 Redission 客戶(hù)端,。Redission 中的鎖方案就是 Redis 分布式鎖的比較完美的詳細(xì)方案,。

那么,，Redission 中的鎖方案為什么會(huì)比較完美呢？

正好,，我用 Redis 做分布式鎖經(jīng)驗(yàn)十分豐富,，在實(shí)際工作中，也探索過(guò)許多種使用 Redis 做分布式鎖的方案,，經(jīng)過(guò)了無(wú)數(shù)血淚教訓(xùn),。

所以，在談及 Redission 鎖為什么比較完美之前,，先給大家看看我曾經(jīng)使用 Redis 做分布式鎖遇到過(guò)的問(wèn)題,。

我曾經(jīng)用 Redis 做分布式鎖想去解決一個(gè)用戶(hù)搶優(yōu)惠券的問(wèn)題。這個(gè)業(yè)務(wù)需求是這樣的：當(dāng)用戶(hù)領(lǐng)完一張優(yōu)惠券后,，優(yōu)惠券的數(shù)量必須相應(yīng)減一,，如果優(yōu)惠券搶光了，就不允許用戶(hù)再搶了,。

在實(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ù)量減一后，寫(xiě)回?cái)?shù)據(jù)庫(kù),。

當(dāng)時(shí)由于請(qǐng)求數(shù)量比較多,，所以，我們使用了三臺(tái)服務(wù)器去做分流,。

這時(shí)候會(huì)出現(xiàn)一個(gè)問(wèn)題：

如果其中一臺(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

原因是這樣做，在沒(méi)有分布式鎖協(xié)調(diào)下,，優(yōu)惠券數(shù)量可能直接會(huì)出現(xiàn)負(fù)數(shù),。因?yàn)楫?dāng)優(yōu)惠券數(shù)量為 1 的時(shí)候，如果兩個(gè)用戶(hù)通過(guò)兩臺(tái)服務(wù)器同時(shí)發(fā)起搶優(yōu)惠券的請(qǐng)求,，都滿(mǎn)足優(yōu)惠券大于 0 的條件,，然后都執(zhí)行這條 SQL 語(yǔ)句，結(jié)果優(yōu)惠券數(shù)量直接變成 -1 了,。

還有人說(shuō)可以用樂(lè)觀鎖,，比如使用如下 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)過(guò)綜合考慮,，我們就采用了 Redis 分布式鎖，通過(guò)互斥的方式,，以防止多個(gè)客戶(hù)端去同時(shí)更新優(yōu)惠券數(shù)量的方案,。

當(dāng)時(shí)，我們首先想到的就是使用 Redis 的 setnx 命令，setnx 命令其實(shí)就是 set if not exists 的簡(jiǎn)寫(xiě),。

當(dāng) key 設(shè)置值成功后,，則返回 1，否則就返回 0,。所以,，這里 setnx 設(shè)置成功可以表示成獲取到鎖，如果失敗,，則說(shuō)明已經(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 指令去釋放鎖,。如果沒(méi)有獲取到,，就等待一定時(shí)間,，重新再去獲取鎖。

乍一看,，這一切沒(méi)什么問(wèn)題，使用 setnx 指令確實(shí)起到了想要的互斥效果,。

但是,，這是建立在所有運(yùn)行環(huán)境都是正常的情況下的。一旦運(yùn)行環(huán)境出現(xiàn)了異常,，問(wèn)題就出現(xiàn)了,。

想一下,，持有鎖的應(yīng)用突然崩潰了,，或者所在的服務(wù)器宕機(jī)了，會(huì)出現(xiàn)什么情況？

這會(huì)造成死鎖——持有鎖的應(yīng)用無(wú)法釋放鎖,，其他應(yīng)用根本也沒(méi)有機(jī)會(huì)再去獲取鎖了,。這會(huì)造成巨大的線(xiàn)上事故，我們要改進(jìn)方案,，解決這個(gè)問(wèn)題,。

怎么解決呢？咱們可以看到,，造成死鎖的根源是,，一旦持有鎖的應(yīng)用出現(xiàn)問(wèn)題，就不會(huì)去釋放鎖,。從這個(gè)方向思考，可以在 Redis 上給 key 一個(gè)過(guò)期時(shí)間,。

這樣的話(huà),，即使出現(xiàn)問(wèn)題，key 也會(huì)在一段時(shí)間后釋放,，是不是就解決了這個(gè)問(wèn)題呢,？實(shí)際上，大家也確實(shí)是這么做的,。

不過(guò),，由于 setnx 這個(gè)指令本身無(wú)法設(shè)置超時(shí)時(shí)間，所以一般會(huì)采用兩種辦法來(lái)做這件事：

1,、采用 lua 腳本,，在使用 setnx 指令之后，再使用 expire 命令去給 key 設(shè)置過(guò)期時(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)問(wèn)題,，導(dǎo)致死鎖了。這樣就完美了嗎,？

假設(shè)有這樣一種情況,，如果一個(gè)持有鎖的應(yīng)用,，其持有的時(shí)間超過(guò)了我們?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 還存在,。這說(shuō)明什么？說(shuō)明當(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)問(wèn)題,。

所以，為了解決這個(gè)問(wèn)題,，我們需要繼續(xù)對(duì) Redis 腳本進(jìn)行改動(dòng)……毀滅吧,，累了……

首先，我們要讓?xiě)?yīng)用在獲取鎖的時(shí)候,，去設(shè)置一個(gè)只有應(yīng)用自己知道的獨(dú)一無(wú)二的值,。

通過(guò)這個(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 的值,，或者通過(guò)雪球算法，生成只有自己持有的唯一 ID,。

釋放鎖的腳本改成這樣：

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

可以看到,，從業(yè)務(wù)角度，無(wú)論如何,，我們的分布式鎖已經(jīng)可以滿(mǎn)足真正的業(yè)務(wù)需求了,。能互斥,，不死鎖,，不會(huì)誤刪除別人的鎖,，只有自己上的鎖，自己可以釋放,。

一切都是那么美好?。?！

可惜,，還有個(gè)隱患，我們并未排除,。這個(gè)隱患就是 Redis 自身,。

要知道，lua 腳本都是用在 Redis 的單例上的,。一旦 Redis 本身出現(xiàn)了問(wèn)題,，我們的分布式鎖就沒(méi)法用了，分布式鎖沒(méi)法用,，對(duì)業(yè)務(wù)的正常運(yùn)行會(huì)造成重大影響,，這是我們無(wú)法接受的。

所以,，我們需要把 Redis 搞成高可用的,。一般來(lái)講，解決 Redis 高可用的問(wèn)題,，都是使用主從集群,。

但是搞主從集群，又會(huì)引入新的問(wèn)題,。主要問(wèn)題在于,，Redis 的主從數(shù)據(jù)同步有延遲。這種延遲會(huì)產(chǎn)生一個(gè)邊界條件：當(dāng)主機(jī)上的 Redis 已經(jīng)被人建好了鎖,，但是鎖數(shù)據(jù)還未同步到從機(jī)時(shí),，主機(jī)宕了。隨后,，從機(jī)提升為主機(jī),，此時(shí)從機(jī)上是沒(méi)有以前主機(jī)設(shè)置好的鎖數(shù)據(jù)的——鎖丟了……丟了……了……

到這里，終于可以介紹 Redission（開(kāi)源 Redis 客戶(hù)端）了,，我們來(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ù),。

我們通過(guò)一個(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)為失敗,。
如果超過(guò) 5 秒，不管幾臺(tái)機(jī)器設(shè)置鎖成功,，都認(rèn)為設(shè)置鎖失敗,。比如，前 4 臺(tái)設(shè)置成功一共花了 3 秒,，但是最后 1 臺(tái)機(jī)器用了 2 秒也沒(méi)結(jié)果,，總的等待時(shí)間已經(jīng)超過(guò)了 5 秒，即使半數(shù)以上成功,，這也算作失敗,。

再額外多說(shuō)一句，在很多業(yè)務(wù)邏輯里,，其實(shí)對(duì)鎖的超時(shí)時(shí)間是沒(méi)有需求的,。

比如，凌晨批量執(zhí)行處理的任務(wù),，可能需要分布式鎖保證任務(wù)不會(huì)被重復(fù)執(zhí)行,。此時(shí)，任務(wù)要執(zhí)行多長(zhǎng)時(shí)間是不明確的,。如果設(shè)置分布式鎖的超時(shí)時(shí)間在這里,，并沒(méi)有太大意義。但是,，不設(shè)置超時(shí)時(shí)間,，又會(huì)引發(fā)死鎖問(wèn)題,。

所以，解決這種問(wèn)題的通用辦法是,，每個(gè)持有鎖的客戶(hù)端都啟動(dòng)一個(gè)后臺(tái)線(xiàn)程,，通過(guò)執(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)的唯一值,，也就是只有持有鎖的客戶(hù)端才能刷新 key 的超時(shí)時(shí)間,。

到此為止，一個(gè)完整的分布式鎖才算實(shí)現(xiàn)完畢,?？偨Y(jié)實(shí)現(xiàn)方案如下：

使用 set 命令設(shè)置鎖標(biāo)記，必須有超時(shí)時(shí)間,，以便客戶(hù)端崩潰,，也可以釋放鎖；
對(duì)于不需要超時(shí)時(shí)間的,，需要自己實(shí)現(xiàn)一個(gè)能不斷刷新鎖超時(shí)時(shí)間的線(xiàn)程,；
每個(gè)獲取鎖的客戶(hù)端，在 Redis 中設(shè)置的 value 必須是獨(dú)一無(wú)二的,，以便識(shí)別出是由哪個(gè)客戶(hù)端設(shè)置的鎖,；
分布式集群中，直接每臺(tái)機(jī)器設(shè)置一樣的超時(shí)時(shí)間和鎖標(biāo)記,；
為了保證集群設(shè)置的鎖不會(huì)因?yàn)榫W(wǎng)絡(luò)問(wèn)題導(dǎo)致某些已經(jīng)設(shè)置的鎖出現(xiàn)超時(shí)的情況,，必須合理設(shè)置網(wǎng)絡(luò)等待時(shí)間和鎖超時(shí)時(shí)間。

這個(gè)分布式鎖滿(mǎn)足如下四個(gè)條件：

任意時(shí)刻只能有一個(gè)客戶(hù)端持有鎖,；
不能發(fā)生死鎖,，有一個(gè)客戶(hù)端持有鎖期間出現(xiàn)了問(wèn)題沒(méi)有解鎖，也能保證后面別的客戶(hù)端繼續(xù)去持有鎖,；
加鎖和解鎖必須是同一個(gè)客戶(hù)端,，客戶(hù)端自己加的鎖只能自己去解；
只要大多數(shù) Redis 節(jié)點(diǎn)正常,，客戶(hù)端就能正常使用鎖,。

當(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ì)方案就寫(xiě)完了,。

我既寫(xiě)了一步一坑的坎坷經(jīng)歷，也寫(xiě)明了各個(gè)問(wèn)題和解決問(wèn)題的細(xì)節(jié),，希望大家看完能有所收獲,。

最后再給大家提個(gè)醒，使用 Redis 集群做分布式鎖,，有一定的爭(zhēng)議性,，還需要大家在實(shí)際用的時(shí)候，根據(jù)現(xiàn)實(shí)情況,，做出更好的選擇和取舍,。

本站是提供個(gè)人知識(shí)管理的網(wǎng)絡(luò)存儲(chǔ)空間，所有內(nèi)容均由用戶(hù)發(fā)布,，不代表本站觀點(diǎn),。請(qǐng)注意甄別內(nèi)容中的聯(lián)系方式、誘導(dǎo)購(gòu)買(mǎi)等信息,，謹(jǐn)防詐騙,。如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請(qǐng)點(diǎn)擊一鍵舉報(bào),。

轉(zhuǎn)藏 分享

QQ空間 QQ好友新浪微博微信

獻(xiàn)花（0） +1

來(lái)自： ZhouAndrew > 《AI&NewIT》

舉報(bào)/認(rèn)領(lǐng)