雲栖号資訊：【 點選檢視更多行業資訊】
在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
談起 Redis 鎖，下面三個，算是出現最多的高頻詞彙：
- Setnx
- RedLock
- Redisson
目前通常所說的 Setnx 指令，并非單指 Redis 的 setnx key value 這條指令。
一般代指 Redis 中對 Set 指令加上 NX 參數進行使用，Set 這個指令，目前已經支援這麼多參數可選：
SET key value [EX seconds|PX milliseconds] [NX|XX] [KEEPTTL] 當然了，就不在文章中默寫 API 了，基礎參數還有不清晰的，可以蹦到官網。
上圖是筆者畫的 Setnx 大緻原理，主要依托了它的 Key 不存在才能 Set 成功的特性，程序 A 拿到鎖，在沒有删除鎖的 Key 時，程序 B 自然擷取鎖就失敗了。
那麼為什麼要使用 PX 30000 去設定一個逾時時間？是怕程序 A 不講道理啊，鎖沒等釋放呢，萬一崩了，直接原地把鎖帶走了，導緻系統中誰也拿不到鎖。
就算這樣，還是不能保證萬無一失。如果程序 A 又不講道理，操作鎖内資源超過筆者設定的逾時時間，那麼就會導緻其他程序拿到鎖，等程序 A 回來了，回手就是把其他程序的鎖删了，如圖：
還是剛才那張圖，将 T5 時刻改成了鎖逾時，被 Redis 釋放。
程序 B 在 T6 開開心心拿到鎖不到一會，程序 A 操作完成，回手一個 Del，就把鎖釋放了。
找不到鎖其實還算好的，萬一 T7 時刻有個程序 C 過來加鎖成功，那麼程序 B 就把程序 C 的鎖釋放了。
以此類推，程序 C 可能釋放程序 D 的鎖，程序 D....(禁止套娃)，具體什麼後果就不得而知了。
是以在用 Setnx 的時候，Key 雖然是主要作用，但是 Value 也不能閑着，可以設定一個唯一的用戶端 ID，或者用 UUID 這種随機數。
當解鎖的時候，先擷取 Value 判斷是否是目前程序加的鎖，再去删除。僞代碼：
String uuid = xxxx;
// 僞代碼，具體實作看項目中用的連接配接工具
// 有的提供的方法名為set 有的叫setIfAbsent
set Test uuid NX PX 3000
try{
// biz handle....
} finally {
// unlock
if(uuid.equals(redisTool.get('Test')){
redisTool.del('Test');
}
} 這回看起來是不是穩了？相反，這回的問題更明顯了，在 Finally 代碼塊中，Get 和 Del 并非原子操作，還是有程序安全問題。
為什麼有問題還說這麼多呢？有如下兩點原因：
- 搞清劣勢所在，才能更好的完善。
- 上文中最後這段代碼，還是有很多公司在用的。
大小項目悖論：
那麼删除鎖的正确姿勢之一，就是可以使用 Lua 腳本，通過 Redis 的 eval/evalsha 指令來運作：
-- lua删除鎖：
-- KEYS和ARGV分别是以集合方式傳入的參數，對應上文的Test和uuid。
-- 如果對應的value等于傳入的uuid。
if redis.call('get', KEYS[1]) == ARGV[1]
then
-- 執行删除操作
return redis.call('del', KEYS[1])
else
-- 不成功，傳回0
return 0
end 通過 Lua 腳本能保證原子性的原因說的通俗一點：就算你在 Lua 裡寫出花，執行也是一個指令（eval/evalsha）去執行的，一條指令沒執行完，其他用戶端是看不到的。
那麼既然這麼麻煩，有沒有比較好的工具呢？就要說到 Redisson 了。
介紹 Redisson 之前，筆者簡單解釋一下為什麼現在的 Setnx 預設是指 Set 指令帶上 NX 參數，而不是直接說是 Setnx 這個指令。
因為 Redis 版本在 2.6.12 之前，Set 是不支援 NX 參數的，如果想要完成一個鎖，那麼需要兩條指令：
1. setnx Test uuid
2. expire Test 30 即放入 Key 和設定有效期，是分開的兩步，理論上會出現 1 剛執行完，程式挂掉，無法保證原子性。
但是早在 2013 年，也就是 7 年前，Redis 就釋出了 2.6.12 版本，并且官網(Set 指令頁)，也早早就說明了“SETNX，SETEX，PSETEX 可能在未來的版本中，會棄用并永久删除”。
筆者曾閱讀過一位大佬的文章，其中就有一句指導入門者的面試小套路，具體文字忘記了，大概意思如下：說到 Redis 鎖的時候，可以先從 Setnx 講起，最後慢慢引出 Set 指令的可以加參數，可以展現出自己的知識面。
如果有緣你也閱讀過這篇文章，并且學到了這個套路，作為本文的筆者我要加一句提醒：請注意你的工作年限！首先回答官網表明即将廢棄的指令，再引出 Set 指令七年前的“新特性”，如果是剛畢業不久的人這麼說，面試官會以為自己穿越了。
Redisson 是 Java 的 Redis 用戶端之一，提供了一些 API 友善操作 Redis。
但是 Redisson 這個用戶端可有點厲害，筆者在官網截了僅僅是一部分的圖：
這個特性清單可以說是太多了，是不是還看到了一些 JUC 包下面的類名，Redisson 幫我們搞了分布式的版本。
比如 AtomicLong，直接用 RedissonAtomicLong 就行了，連類名都不用去新記，很人性化了。
鎖隻是它的冰山一角，并且從它的 Wiki 頁面看到，對主從，哨兵，叢集等模式都支援，當然了，單節點模式肯定是支援的。
本文還是以鎖為主，其他的不過多介紹。Redisson 普通的鎖實作源碼主要是 RedissonLock 這個類，還沒有看過它源碼的盆友，不妨去瞧一瞧。
源碼中加鎖/釋放鎖操作都是用 Lua 腳本完成的，封裝的非常完善，開箱即用。
這裡有個小細節，加鎖使用 Setnx 就能實作，也采用 Lua 腳本是不是多此一舉？
筆者也非常嚴謹的思考了一下：這麼厲害的東西哪能寫廢代碼？
其實筆者仔細看了一下，加鎖解鎖的 Lua 腳本考慮的非常全面，其中就包括鎖的重入性，這點可以說是考慮非常周全，我也随手寫了代碼測試一下：
的确用起來像 JDK 的 ReentrantLock 一樣絲滑，那麼 Redisson 實作的已經這麼完善，RedLock 又是什麼？
RedLock的中文是直譯過來的，就叫紅鎖。紅鎖并非是一個工具，而是 Redis 官方提出的一種分布式鎖的算法。
就在剛剛介紹完的 Redisson 中，就實作了 RedLock 版本的鎖。也就是說除了 getLock 方法，還有 getRedLock 方法。
筆者大概畫了一下對紅鎖的了解：
如果你不熟悉 Redis 高可用部署，那麼沒關系。RedLock 算法雖然是需要多個執行個體，但是這些執行個體都是獨自部署的，沒有主從關系。
RedLock 作者指出，之是以要用獨立的，是避免了 Redis 異步複制造成的鎖丢失，比如：主節點沒來的及把剛剛 Set 進來這條資料給從節點，就挂了。
有些人是不是覺得大佬們都是杠精啊，天天就想着極端情況。其實高可用嘛，拼的就是 99.999...% 中小數點後面的位數。
回到上面那張簡陋的圖檔，紅鎖算法認為，隻要 2N+1 個節點加鎖成功，那麼就認為擷取了鎖， 解鎖時将所有執行個體解鎖。
流程為：
- 順序向五個節點請求加鎖
- 根據一定的逾時時間來推斷是不是跳過該節點
- 三個節點加鎖成功并且花費時間小于鎖的有效期
- 認定加鎖成功
也就是說，假設鎖 30 秒過期，三個節點加鎖花了 31 秒，自然是加鎖失敗了。
這隻是舉個例子，實際上并不應該等每個節點那麼長時間，就像官網所說的那樣，假設有效期是 10 秒，那麼單個 Redis 執行個體操作逾時時間，應該在 5 到 50 毫秒(注意時間機關)。
還是假設我們設定有效期是 30 秒，圖中逾時了兩個 Redis 節點。那麼加鎖成功的節點總共花費了 3 秒，是以鎖的實際有效期是小于 27 秒的。
即扣除加鎖成功三個執行個體的 3 秒，還要扣除等待逾時 Redis 執行個體的總共時間。看到這，你有可能對這個算法有一些疑問，那麼你不是一個人。
回頭看看 Redis 官網關于紅鎖的描述，就在這篇描述頁面的最下面，你能看到著名的關于紅鎖的神仙打架事件。
即 Martin Kleppmann 和 Antirez 的 RedLock 辯論。一個是很有資曆的分布式架構師，一個是 Redis 之父。
官方挂人，最為緻命。開個玩笑，要是質疑能被官方挂到官網，說明肯定是有價值的。
是以說如果項目裡要使用紅鎖，除了紅鎖的介紹，不妨要多看兩篇文章，即：
- Martin Kleppmann 的質疑貼
- Antirez 的反擊貼
總結
看了這麼多，是不是發現如何實作，都不能保證 100% 的穩定。程式就是這樣，沒有絕對的穩定，是以做好人工補償環節也是重要的一環，畢竟：技術不夠，人工來湊！
【雲栖号線上課堂】每天都有産品技術專家分享！
課程位址：
https://yqh.aliyun.com/zhibo立即加入社群，與專家面對面，及時了解課程最新動态！
【雲栖号線上課堂 社群】
https://c.tb.cn/F3.Z8gvnK
原文釋出時間：2020-03-25
本文作者：：Vt
本文來自：“
網際網路架構師 微信公衆号”，了解相關資訊可以關注“
網際網路架構師”