談起redis鎖，下面三個，算是出現最多的高頻詞彙：

• setnx
• redLock
• redisson

setnx

　　其實目前通常所說的setnx命令，並非單指redis的setnx key value這條命令。一般代指redis中對set命令加上nx引數進行使用， set這個命令，目前已經支援這麼多引數可選：

SET key value [EX seconds|PX milliseconds] [NX|XX] [KEEPTTL]

　　當然了，就不在文章中默寫Api了，基礎引數還有不清晰的，可以蹦到官網。

　　上圖是筆者畫的setnx大致原理，主要依託了它的key不存在才能set成功的特性

　　如果程序A又不講道理，操作鎖內資源超過筆者設定的超時時間，那麼就會導致其他程序拿到鎖，等程序A回來了，回手就是把其他程序的鎖刪了，如圖：

　　還是剛才那張圖，將T5時刻改成了鎖超時，被redis釋放。程序B在T6開開心心拿到鎖不到一會，程序A操作完成，回手一個del，就把鎖釋放了。當程序B操作完成，去釋放鎖的時候（圖中T8時刻）：找不到鎖其實還算好的，萬一T7

　　所以在用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

　　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個節點加鎖成功，那麼就認為獲取了鎖， 解鎖時將所有例項解鎖。流程為：

1. 順序向五個節點請求加鎖
2. 根據一定的超時時間來推斷是不是跳過該節點
3. 三個節點加鎖成功並且花費時間小於鎖的有效期
4. 認定加鎖成功

　　也就是說，假設鎖30秒過期，三個節點加鎖花了31秒，自然是加鎖失敗了。這只是舉個例子，實際上並不應該等每個節點那麼長時間，就像官網所說的那樣，假設有效期是10秒，那麼單個redis例項操作超時時間，應該在5到50毫秒(注意時間單位).還是假設我們設定有效期是30秒，圖中超時了兩個redis節點。那麼加鎖成功的節點總共花費了3秒，所以鎖的實際有效期是小於27秒的。即扣除加鎖成功三個例項的3秒，還要扣除等待超時redis例項的總共時間。看到這，你有可能對這個演算法有一些疑問，那麼你不是一個人。回頭看看Redis官網關於紅鎖的描述.就在這篇描述頁面的最下面，你能看到著名的關於紅鎖的神仙打架事件。

　　即Martin Kleppmann和antirez的redLock辯論. 一個是很有資歷的分散式架構師，一個是redis之父。

　　所以說如果專案裡要使用紅鎖，除了紅鎖的介紹，不妨要多看兩篇文章，即：

Martin Kleppmann的質疑貼
antirez的反擊貼

總結

　　看了這麼多，是不是發現如何實現，都不能保證100%的穩定。程式就是這樣，沒有絕對的穩定，所以做好人工補償環節也是重要的一環，畢竟：技術不夠，人工來湊～

來源: 程式設計師DD, 程式設計師小灰, macrozheng