Redis鎖被別人釋放怎么辦
本文轉(zhuǎn)載自微信公眾號(hào)「后端Q」，作者conan 。轉(zhuǎn)載本文請(qǐng)聯(lián)系后端Q公眾號(hào)。
什么是分布式鎖?
要介紹分布式鎖，首先要提到與分布式鎖相對(duì)應(yīng)的是線程鎖、進(jìn)程鎖。
線程鎖：主要用來(lái)給方法、代碼塊加鎖。當(dāng)某個(gè)方法或代碼使用鎖，在同一時(shí)刻僅有一個(gè)線程執(zhí)行該方法或該代碼段。線程鎖只在同一JVM中有效果，因?yàn)榫€程鎖的實(shí)現(xiàn)在根本上是依靠線程之間共享內(nèi)存實(shí)現(xiàn)的，比如synchronized是共享對(duì)象頭，顯示鎖Lock是共享某個(gè)變量(state)。
進(jìn)程鎖：為了控制同一操作系統(tǒng)中多個(gè)進(jìn)程訪問(wèn)某個(gè)共享資源，因?yàn)檫M(jìn)程具有獨(dú)立性，各個(gè)進(jìn)程無(wú)法訪問(wèn)其他進(jìn)程的資源，因此無(wú)法通過(guò)synchronized等線程鎖實(shí)現(xiàn)進(jìn)程鎖。
問(wèn)題窺探
分布式鎖：當(dāng)多個(gè)進(jìn)程不在同一個(gè)系統(tǒng)中，用分布式鎖控制多個(gè)進(jìn)程對(duì)資源的訪問(wèn)。有這樣一個(gè)情境，線程A和線程B都共享某個(gè)變量X。如果是分布式情況下，線程A和線程B很可能不是在同一對(duì)象中，每個(gè)客戶端在釋放鎖時(shí)，都是刪除操作，并沒(méi)有檢查這把鎖是否還是自己的，所以就會(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)過(guò)期的問(wèn)題。之后，在釋放鎖時(shí)，要先判斷這把鎖是否還歸自己持有，偽代碼可以這么寫：
- // 鎖是自己的，才釋放
- if redis.get("lock") == $uuid:
- redis.del("lock")
這里釋放鎖使用的是 GET + DEL 兩條命令，這時(shí)，又會(huì)遇到我們前面講的原子性問(wèn)題了。
客戶端 1 執(zhí)行 GET，判斷鎖是自己的
客戶端 2 執(zhí)行了 SET 命令，強(qiáng)制獲取到鎖(雖然發(fā)生概率比較低，但我們需要嚴(yán)謹(jǐn)?shù)乜紤]鎖的安全性模型)
客戶端 1 執(zhí)行 DEL，卻釋放了客戶端 2 的鎖
由此可見(jiàn)，這兩個(gè)命令還是必須要原子執(zhí)行才行。
怎樣原子執(zhí)行呢?Lua 腳本。
我們可以把這個(gè)邏輯，寫成 Lua 腳本，讓 Redis 來(lái)執(zhí)行。
因?yàn)?Redis 處理每一個(gè)請(qǐng)求是單線程執(zhí)行的，在執(zhí)行一個(gè) Lua 腳本時(shí)，其它請(qǐng)求必須等待，直到這個(gè) Lua 腳本處理完成，這樣一來(lái)，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 釋放鎖
