[[427025]]

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

什么是分布式鎖?

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

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

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

問題窺探

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

解決辦法

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

加鎖：SET lock_key $unique_id EX $expire_time NX 

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