什么是分布式鎖？

要介紹分布式鎖，首先要提到與分布式鎖相對應的是線程鎖、進程鎖。e8H28資訊網——每日最新資訊28at.com

• 線程鎖：主要用來給方法、代碼塊加鎖。當某個方法或代碼使用鎖，在同一時刻僅有一個線程執(zhí)行該方法或該代碼段。線程鎖只在同一JVM中有效果，因為線程鎖的實現在根本上是依靠線程之間共享內存實現的，比如synchronized是共享對象頭，顯示鎖Lock是共享某個變量（state）。
• 進程鎖：為了控制同一操作系統中多個進程訪問某個共享資源，因為進程具有獨立性，各個進程無法訪問其他進程的資源，因此無法通過synchronized等線程鎖實現進程鎖。

e8H28資訊網——每日最新資訊28at.com

問題窺探

分布式鎖：當多個進程不在同一個系統中，用分布式鎖控制多個進程對資源的訪問。e8H28資訊網——每日最新資訊28at.com

有這樣一個情境，線程A和線程B都共享某個變量X。如果是分布式情況下，線程A和線程B很可能不是在同一對象中，每個客戶端在釋放鎖時，都是刪除操作，并沒有檢查這把鎖是否還是自己的，所以就會發(fā)生釋放別人鎖的風險。e8H28資訊網——每日最新資訊28at.com

解決辦法

客戶端在加鎖時，設置一個只有自己知道的唯一標識進去。例如，可以是自己的線程 ID，也可以是一個 UUID（隨機且唯一），這里我們以 UUID 舉例：e8H28資訊網——每日最新資訊28at.com

// 鎖的VALUE設置為UUID127.0.0.1:6379> SET lock $uuid EX 20 NXOK

這里假設 20s 操作共享時間完全足夠，先不考慮鎖自動過期的問題。之后，在釋放鎖時，要先判斷這把鎖是否還歸自己持有，偽代碼可以這么寫：e8H28資訊網——每日最新資訊28at.com

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

這里釋放鎖使用的是 GET + DEL 兩條命令，這時，又會遇到我們前面講的原子性問題了。e8H28資訊網——每日最新資訊28at.com

• 客戶端 1 執(zhí)行 GET，判斷鎖是自己的
• 客戶端 2 執(zhí)行了 SET 命令，強制獲取到鎖（雖然發(fā)生概率比較低，但我們需要嚴謹地考慮鎖的安全性模型）
• 客戶端 1 執(zhí)行 DEL，卻釋放了客戶端 2 的鎖

由此可見，這兩個命令還是必須要原子執(zhí)行才行。e8H28資訊網——每日最新資訊28at.com

怎樣原子執(zhí)行呢？Lua 腳本。e8H28資訊網——每日最新資訊28at.com

我們可以把這個邏輯，寫成 Lua 腳本，讓 Redis 來執(zhí)行。e8H28資訊網——每日最新資訊28at.com

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

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

好了，這樣一路優(yōu)化，整個的加鎖、解鎖的流程就更嚴謹了。e8H28資訊網——每日最新資訊28at.com

這里我們先小結一下，基于 Redis 實現的分布式鎖，一個嚴謹的的流程如下：e8H28資訊網——每日最新資訊28at.com

加鎖：SET lock_key $unique_id EX $expire_time NX

操作共享資源 釋放鎖：Lua 腳本，先 GET 判斷鎖是否歸屬自己，再 DEL 釋放鎖。e8H28資訊網——每日最新資訊28at.com

本文鏈接：http://www.www897cc.com/showinfo-26-76568-0.htmlRedis鎖被別人釋放怎么辦

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com

上一篇： 我面試最喜歡問的開放題：如何嚴謹二次封裝 localStorage？

下一篇： Java程序員易踩的坑及解析