[[427025]]

本文轉(zhuǎn)載自微信公眾號(hào)「后端Q」，作者conan 。轉(zhuǎn)載本文請聯(lián)系后端Q公眾號(hào)。

什么是分布式鎖?

要介紹分布式鎖，首先要提到與分布式鎖相對應(yīng)的是線程鎖、進(jìn)程鎖。

線程鎖：主要用來給方法、代碼塊加鎖。當(dāng)某個(gè)方法或代碼使用鎖，在同一時(shí)刻僅有一個(gè)線程執(zhí)行該方法或該代碼段。線程鎖只在同一JVM中有效果，因?yàn)榫€程鎖的實(shí)現(xiàn)在根本上是依靠線程之間共享內(nèi)存實(shí)現(xiàn)的，比如synchronized是共享對象頭，顯示鎖Lock是共享某個(gè)變量(state)。

進(jìn)程鎖：為了控制同一操作系統(tǒng)中多個(gè)進(jìn)程訪問某個(gè)共享資源，因?yàn)檫M(jìn)程具有獨(dú)立性，各個(gè)進(jìn)程無法訪問其他進(jìn)程的資源，因此無法通過synchronized等線程鎖實(shí)現(xiàn)進(jìn)程鎖。

問題窺探

分布式鎖：當(dāng)多個(gè)進(jìn)程不在同一個(gè)系統(tǒng)中，用分布式鎖控制多個(gè)進(jìn)程對資源的訪問。有這樣一個(gè)情境，線程A和線程B都共享某個(gè)變量X。如果是分布式情況下，線程A和線程B很可能不是在同一對象中，每個(gè)客戶端在釋放鎖時(shí)，都是刪除操作，并沒有檢查這把鎖是否還是自己的，所以就會(huì)發(fā)生釋放別人鎖的風(fēng)險(xiǎn)。

解決辦法

客戶端在加鎖時(shí)，設(shè)置一個(gè)只有自己知道的唯一標(biāo)識(shí)進(jìn)去。例如，可以是自己的線程 ID，也可以是一個(gè) UUID(隨機(jī)且唯一)，這里我們以 UUID 舉例：

// 鎖的VALUE設(shè)置為UUID 
127.0.0.1:6379> SET lock $uuid EX 20 NX 
OK 

這里假設(shè) 20s 操作共享時(shí)間完全足夠，先不考慮鎖自動(dòng)過期的問題。之后，在釋放鎖時(shí)，要先判斷這把鎖是否還歸自己持有，偽代碼可以這么寫：

// 鎖是自己的，才釋放 
if redis.get("lock") == $uuid: 
    redis.del("lock") 
     

這里釋放鎖使用的是 GET + DEL 兩條命令，這時(shí)，又會(huì)遇到我們前面講的原子性問題了。

客戶端 1 執(zhí)行 GET，判斷鎖是自己的

客戶端 2 執(zhí)行了 SET 命令，強(qiáng)制獲取到鎖(雖然發(fā)生概率比較低，但我們需要嚴(yán)謹(jǐn)?shù)乜紤]鎖的安全性模型)

客戶端 1 執(zhí)行 DEL，卻釋放了客戶端 2 的鎖

由此可見，這兩個(gè)命令還是必須要原子執(zhí)行才行。

怎樣原子執(zhí)行呢?Lua 腳本。

我們可以把這個(gè)邏輯，寫成 Lua 腳本，讓 Redis 來執(zhí)行。

因?yàn)?Redis 處理每一個(gè)請求是單線程執(zhí)行的，在執(zhí)行一個(gè) Lua 腳本時(shí)，其它請求必須等待，直到這個(gè) Lua 腳本處理完成，這樣一來，GET + DEL 之間就不會(huì)插入其它命令了。安全釋放鎖的 Lua 腳本如下：

// 判斷鎖是自己的，才釋放 
if redis.call("GET",KEYS[1]) == ARGV[1] 
then 
    return redis.call("DEL",KEYS[1]) 
else 
    return 0 
end 

好了，這樣一路優(yōu)化，整個(gè)的加鎖、解鎖的流程就更嚴(yán)謹(jǐn)了。

這里我們先小結(jié)一下，基于 Redis 實(shí)現(xiàn)的分布式鎖，一個(gè)嚴(yán)謹(jǐn)?shù)牡牧鞒倘缦拢?/p>

加鎖：SET lock_key $unique_id EX $expire_time NX 

操作共享資源 釋放鎖：Lua 腳本，先 GET 判斷鎖是否歸屬自己，再 DEL 釋放鎖