Redis如何實(shí)現(xiàn)分布式鎖

更新時(shí)間：2023年10月09日 10:11:36 作者：下次一定少寫B(tài)UG

這篇文章主要介紹了Redis如何實(shí)現(xiàn)分布式鎖問題,具有很好的參考價(jià)值,希望對(duì)大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教

Redis實(shí)現(xiàn)分布式鎖

分布式鎖是用于分布式環(huán)境下并發(fā)控制的一種機(jī)制，用于控制某個(gè)資源在同一時(shí)刻只能被一個(gè)應(yīng)用所使用。

如下圖所示：

Redis 本身可以被多個(gè)客戶端共享訪問，正好就是一個(gè)共享存儲(chǔ)系統(tǒng)，可以用來保存分布式鎖，而且 Redis 的讀寫性能高，可以應(yīng)對(duì)高并發(fā)的鎖操作場景。

Redis 的 SET 命令有個(gè) NX 參數(shù)可以實(shí)現(xiàn)「key不存在才插入」，所以可以用它來實(shí)現(xiàn)分布式鎖：

如果 key 不存在，則顯示插入成功，可以用來表示加鎖成功；
如果 key 存在，則會(huì)顯示插入失敗，可以用來表示加鎖失敗。

基于 Redis 節(jié)點(diǎn)實(shí)現(xiàn)分布式鎖時(shí)，對(duì)于加鎖操作，我們需要滿足三個(gè)條件。

加鎖包括了讀取鎖變量、檢查鎖變量值和設(shè)置鎖變量值三個(gè)操作，但需要以原子操作的方式完成，所以，我們使用 SET 命令帶上 NX 選項(xiàng)來實(shí)現(xiàn)加鎖；
鎖變量需要設(shè)置過期時(shí)間，以免客戶端拿到鎖后發(fā)生異常，導(dǎo)致鎖一直無法釋放，所以，我們?cè)?SET 命令執(zhí)行時(shí)加上 EX/PX 選項(xiàng)，設(shè)置其過期時(shí)間；
鎖變量的值需要能區(qū)分來自不同客戶端的加鎖操作，以免在釋放鎖時(shí)，出現(xiàn)誤釋放操作，所以，我們使用 SET 命令設(shè)置鎖變量值時(shí)，每個(gè)客戶端設(shè)置的值是一個(gè)唯一值，用于標(biāo)識(shí)客戶端；

滿足這三個(gè)條件的分布式命令

如下：

SET lock_key unique_value NX PX 10000

lock_key 就是 key 鍵；
unique_value 是客戶端生成的唯一的標(biāo)識(shí)，區(qū)分來自不同客戶端的鎖操作；
NX 代表只在 lock_key 不存在時(shí)，才對(duì) lock_key 進(jìn)行設(shè)置操作；
PX 10000 表示設(shè)置 lock_key 的過期時(shí)間為 10s，這是為了避免客戶端發(fā)生異常而無法釋放鎖。

而解鎖的過程就是將 lock_key 鍵刪除（del lock_key），但不能亂刪，要保證執(zhí)行操作的客戶端就是加鎖的客戶端。

所以，解鎖的時(shí)候，我們要先判斷鎖的 unique_value 是否為加鎖客戶端，是的話，才將 lock_key 鍵刪除。

可以看到，解鎖是有兩個(gè)操作，這時(shí)就需要 Lua 腳本來保證解鎖的原子性，因?yàn)?Redis 在執(zhí)行 Lua 腳本時(shí)，可以以原子性的方式執(zhí)行，保證了鎖釋放操作的原子性。

// 釋放鎖時(shí)，先比較 unique_value 是否相等，避免鎖的誤釋放
if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

這樣一來，就通過使用 SET 命令和 Lua 腳本在 Redis 單節(jié)點(diǎn)上完成了分布式鎖的加鎖和解鎖。

基于Redis 實(shí)現(xiàn)分布式鎖有什么優(yōu)缺點(diǎn)？

Redis 實(shí)現(xiàn)分布式鎖的 優(yōu)點(diǎn)：

性能高效（這是選擇緩存實(shí)現(xiàn)分布式鎖最核心的出發(fā)點(diǎn)）。
實(shí)現(xiàn)方便。很多研發(fā)工程師選擇使用 Redis 來實(shí)現(xiàn)分布式鎖，很大成分上是因?yàn)?Redis 提供了 setnx 方法，實(shí)現(xiàn)分布式鎖很方便。
避免單點(diǎn)故障（因?yàn)?Redis 是跨集群部署的，自然就避免了單點(diǎn)故障）。

Redis 實(shí)現(xiàn)分布式鎖的 缺點(diǎn)：

超時(shí)時(shí)間不好設(shè)置。如果鎖的超時(shí)時(shí)間設(shè)置過長，會(huì)影響性能，如果設(shè)置的超時(shí)時(shí)間過短會(huì)保護(hù)不到共享資源。比如在有些場景中，一個(gè)線程 A 獲取到了鎖之后，由于業(yè)務(wù)代碼執(zhí)行時(shí)間可能比較長，導(dǎo)致超過了鎖的超時(shí)時(shí)間，自動(dòng)失效，注意 A 線程沒執(zhí)行完，后續(xù)線程 B 又意外的持有了鎖，意味著可以操作共享資源，那么兩個(gè)線程之間的共享資源就沒辦法進(jìn)行保護(hù)了。
那么如何合理設(shè)置超時(shí)時(shí)間呢？我們可以基于續(xù)約的方式設(shè)置超時(shí)時(shí)間：先給鎖設(shè)置一個(gè)超時(shí)時(shí)間，然后啟動(dòng)一個(gè)守護(hù)線程，讓守護(hù)線程在一段時(shí)間后，重新設(shè)置這個(gè)鎖的超時(shí)時(shí)間。實(shí)現(xiàn)方式就是：寫一個(gè)守護(hù)線程，然后去判斷鎖的情況，當(dāng)鎖快失效的時(shí)候，再次進(jìn)行續(xù)約加鎖，當(dāng)主線程執(zhí)行完成后，銷毀續(xù)約鎖即可，不過這種方式實(shí)現(xiàn)起來相對(duì)復(fù)雜。
Redis 主從復(fù)制模式中的數(shù)據(jù)是異步復(fù)制的，這樣導(dǎo)致分布式鎖的不可靠性。如果在 Redis 主節(jié)點(diǎn)獲取到鎖后，在沒有同步到其他節(jié)點(diǎn)時(shí)，Redis 主節(jié)點(diǎn)宕機(jī)了，此時(shí)新的 Redis 主節(jié)點(diǎn)依然可以獲取鎖，所以多個(gè)應(yīng)用服務(wù)就可以同時(shí)獲取到鎖。

Redis如何解決集群情況下分布式鎖的可靠性？

為了保證集群環(huán)境下分布式鎖的可靠性，Redis 官方已經(jīng)設(shè)計(jì)了一個(gè)分布式鎖算法 Redlock（紅鎖）。

它是基于多個(gè) Redis 節(jié)點(diǎn)的分布式鎖，即使有節(jié)點(diǎn)發(fā)生了故障，鎖變量仍然是存在的，客戶端還是可以完成鎖操作。

官方推薦是至少部署 5 個(gè) Redis 節(jié)點(diǎn)，而且都是主節(jié)點(diǎn)，它們之間沒有任何關(guān)系，都是一個(gè)個(gè)孤立的節(jié)點(diǎn)。

Redlock 算法的基本思路，是讓客戶端和多個(gè)獨(dú)立的 Redis 節(jié)點(diǎn)依次請(qǐng)求申請(qǐng)加鎖，如果客戶端能夠和半數(shù)以上的節(jié)點(diǎn)成功地完成加鎖操作，那么我們就認(rèn)為，客戶端成功地獲得分布式鎖，否則加鎖失敗。

這樣一來，即使有某個(gè) Redis 節(jié)點(diǎn)發(fā)生故障，因?yàn)殒i的數(shù)據(jù)在其他節(jié)點(diǎn)上也有保存，所以客戶端仍然可以正常地進(jìn)行鎖操作，鎖的數(shù)據(jù)也不會(huì)丟失。

Redlock算法加鎖三個(gè)過程

第一步是，客戶端獲取當(dāng)前時(shí)間（t1）。

第二步是，客戶端按順序依次向 N 個(gè) Redis 節(jié)點(diǎn)執(zhí)行加鎖操作：

加鎖操作使用 SET 命令，帶上 NX，EX/PX 選項(xiàng)，以及帶上客戶端的唯一標(biāo)識(shí)。
如果某個(gè) Redis 節(jié)點(diǎn)發(fā)生故障了，為了保證在這種情況下，Redlock 算法能夠繼續(xù)運(yùn)行，我們需要給「加鎖操作」設(shè)置一個(gè)超時(shí)時(shí)間（不是對(duì)「鎖」設(shè)置超時(shí)時(shí)間，而是對(duì)「加鎖操作」設(shè)置超時(shí)時(shí)間），加鎖操作的超時(shí)時(shí)間需要遠(yuǎn)遠(yuǎn)地小于鎖的過期時(shí)間，一般也就是設(shè)置為幾十毫秒。

第三步是，一旦客戶端從超過半數(shù)（大于等于 N/2+1）的 Redis 節(jié)點(diǎn)上成功獲取到了鎖，就再次獲取當(dāng)前時(shí)間（t2），然后計(jì)算計(jì)算整個(gè)加鎖過程的總耗時(shí)（t2-t1）。如果 t2-t1 < 鎖的過期時(shí)間，此時(shí)，認(rèn)為客戶端加鎖成功，否則認(rèn)為加鎖失敗。