談起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，就把鎖釋放了。
當程序B操作完成，去釋放鎖的時候（圖中T8時刻）：
找不到鎖其實還算好的，萬一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指令七年前的“新特性”，如果是剛畢業不久的人這麼說，面試官會以為自己穿越了。
你套路面試官，面試官也會套路你。 -- vt・沃茲基碩德
Redisson
Redisson是java的redis用戶端之一，提供了一些api友善操作redis。
但是redisson這個用戶端可有點厲害，筆者在官網截了僅僅是一部分的圖：
這個特性清單可以說是太多了，是不是還看到了一些JUC包下面的類名，redisson幫我們搞了分布式的版本，比如AtomicLong，直接用RedissonAtomicLong就行了，連類名都不用去新記，很人性化了。
鎖隻是它的冰山一角，并且從它的wiki頁面看到，對主從，哨兵，叢集等模式都支援，當然了，單節點模式肯定是支援的。
本文還是以鎖為主，其他的不過多介紹。
Redisson普通的鎖實作源碼主要是RedissonLock這個類，還沒有看過它源碼的盆友，不妨去瞧一瞧。
源碼中加鎖/釋放鎖操作都是用lua腳本完成的，封裝的非常完善，開箱即用。
這裡有個小細節，加鎖使用setnx就能實作，也采用lua腳本是不是多此一舉？筆者也非常嚴謹的思考了一下：這麼厲害的東西哪能寫廢代碼？
其實筆者仔細看了一下，加鎖解鎖的lua腳本考慮的非常全面，其中就包括鎖的重入性，這點可以說是考慮非常周全，我也随手寫了代碼測試一下：
的确用起來像jdk的ReentrantLock一樣絲滑，那麼redisson實作的已經這麼完善，redLock又是什麼？
RedLock
redLock的中文是直譯過來的，就叫紅鎖。
紅鎖并非是一個工具，而是redis官方提出的一種分布式鎖的算法。
就在剛剛介紹完的redisson中，就實作了redLock版本的鎖。也就是說除了getLock方法，還有getRedLock方法。
筆者大概畫了一下對紅鎖的了解：
如果你不熟悉redis高可用部署，那麼沒關系。redLock算法雖然是需要多個執行個體，但是這些執行個體都是獨自部署的，沒有主從關系。
RedLock作者指出，之是以要用獨立的，是避免了redis異步複制造成的鎖丢失，比如：主節點沒來的及把剛剛set進來這條資料給從節點，就挂了。
有些人是不是覺得大佬們都是杠精啊，天天就想着極端情況。其實高可用嘛，拼的就是99.999...% 中小數點後面的位數。
回到上面那張簡陋的圖檔，紅鎖算法認為，隻要(N/2) + 1個節點加鎖成功，那麼就認為擷取了鎖， 解鎖時将所有執行個體解鎖。流程為：
- 順序向五個節點請求加鎖
- 根據一定的逾時時間來推斷是不是跳過該節點
- 三個節點加鎖成功并且花費時間小于鎖的有效期
- 認定加鎖成功
也就是說，假設鎖30秒過期，三個節點加鎖花了31秒，自然是加鎖失敗了。
這隻是舉個例子，實際上并不應該等每個節點那麼長時間，就像官網所說的那樣，假設有效期是10秒，那麼單個redis執行個體操作逾時時間，應該在5到50毫秒(注意時間機關)
還是假設我們設定有效期是30秒，圖中逾時了兩個redis節點。那麼加鎖成功的節點總共花費了3秒，是以鎖的實際有效期是小于27秒的。
即扣除加鎖成功三個執行個體的3秒，還要扣除等待逾時redis執行個體的總共時間。
看到這，你有可能對這個算法有一些疑問，那麼你不是一個人。
回頭看看Redis官網關于紅鎖的描述
就在這篇描述頁面的最下面，你能看到著名的關于紅鎖的神仙打架事件。
即Martin Kleppmann和antirez的redLock辯論. 一個是很有資曆的分布式架構師，一個是redis之父。
官方挂人，最為緻命。
開個玩笑，要是質疑能被官方挂到官網，說明肯定是有價值的。
是以說如果項目裡要使用紅鎖，除了紅鎖的介紹，不妨要多看兩篇文章，即：
- Martin Kleppmann的質疑貼
- antirez的反擊貼
總結
看了這麼多，是不是發現如何實作，都不能保證100%的穩定。
程式就是這樣，沒有絕對的穩定，是以做好人工補償環節也是重要的一環，畢竟：
技術不夠，人工來湊～
往期推薦
HTTP/3 來了 ！HTTP/2 還沒怎麼用起來呢，先一起掃個盲吧！
Nacos 1.3.0 釋出，一個修煉内功的版本：全新核心建構！
微軟 WinGet 抄襲 AppGet 始末，個人開源的困境該如何破？
架構師究竟要不要寫代碼？
面試：String 五連殺 ！你還滿血嗎 ？
前段時間組織過一波，關于面試内容的學習與讨論，效果還不錯。有兄弟提議可以考慮把大家一起分享或者讀到的幹貨内容都整理起來，除了我們自己查閱友善，可能也對其他人也會很有幫助。是以，我們決定一起弄個以「後端面試」為主題的公衆号，平日主要推送一些面試中常見的技術點幹貨，以幫助大家學習和備戰面試！