Redis鎖被別人釋放怎么辦
什么是分布式鎖？
要介紹分布式鎖，首先要提到與分布式鎖相對應(yīng)的是線程鎖、進(jìn)程鎖。
- 線程鎖：主要用來給方法、代碼塊加鎖。當(dāng)某個方法或代碼使用鎖，在同一時刻僅有一個線程執(zhí)行該方法或該代碼段。線程鎖只在同一JVM中有效果，因?yàn)榫€程鎖的實(shí)現(xiàn)在根本上是依靠線程之間共享內(nèi)存實(shí)現(xiàn)的，比如synchronized是共享對象頭，顯示鎖Lock是共享某個變量（state）。
- 進(jìn)程鎖：為了控制同一操作系統(tǒng)中多個進(jìn)程訪問某個共享資源，因?yàn)檫M(jìn)程具有獨(dú)立性，各個進(jìn)程無法訪問其他進(jìn)程的資源，因此無法通過synchronized等線程鎖實(shí)現(xiàn)進(jìn)程鎖。
問題窺探
分布式鎖：當(dāng)多個進(jìn)程不在同一個系統(tǒng)中，用分布式鎖控制多個進(jìn)程對資源的訪問。
有這樣一個情境，線程A和線程B都共享某個變量X。如果是分布式情況下，線程A和線程B很可能不是在同一對象中，每個客戶端在釋放鎖時，都是刪除操作，并沒有檢查這把鎖是否還是自己的，所以就會發(fā)生釋放別人鎖的風(fēng)險。
解決辦法
客戶端在加鎖時，設(shè)置一個只有自己知道的唯一標(biāo)識進(jìn)去。例如，可以是自己的線程 ID，也可以是一個 UUID（隨機(jī)且唯一），這里我們以 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 命令，強(qiáng)制獲取到鎖（雖然發(fā)生概率比較低，但我們需要嚴(yán)謹(jǐn)?shù)乜紤]鎖的安全性模型）
- 客戶端 1 執(zhí)行 DEL，卻釋放了客戶端 2 的鎖
由此可見，這兩個命令還是必須要原子執(zhí)行才行。
怎樣原子執(zhí)行呢？Lua 腳本。
我們可以把這個邏輯，寫成 Lua 腳本，讓 Redis 來執(zhí)行。
因?yàn)?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)化，整個的加鎖、解鎖的流程就更嚴(yán)謹(jǐn)了。
這里我們先小結(jié)一下，基于 Redis 實(shí)現(xiàn)的分布式鎖，一個嚴(yán)謹(jǐn)?shù)牡牧鞒倘缦拢?/p>
加鎖：SET lock_key $unique_id EX $expire_time NX操作共享資源 釋放鎖：Lua 腳本，先 GET 判斷鎖是否歸屬自己，再 DEL 釋放鎖。
