一篇關於redis鎖的文章--Redis分佈式鎖

序-碎碎叨叨

在家辦公的第N周，

也不知道筆者工位上的鍵盤和顯示器有沒有想我，

不知道會不會落灰太嚴重，被保潔阿姨扔掉了。

---

筆者今天帶來一篇關於redis鎖的文章

連敲帶畫碼出此文，有一些細節，對redis鎖不清晰的盆友不妨瞧一瞧。

若是是有經驗的盆友，挑挑毛病，那筆者是更感謝了～

閒話很少，立刻發車。

正文-開門見山

談起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拿到鎖，在沒有刪除鎖的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 有的叫setIfAbsentset Test uuid NX PX 3000try{// 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 uuid2. 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...%中小數點後面的位數。

回到上面那張簡陋的圖片，紅鎖算法認爲，只要2N + 1個節點加鎖成功，那麼就認爲獲取了鎖， 解鎖時將全部實例解鎖。 流程爲：

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

也就是說，假設鎖30秒過時，三個節點加鎖花了31秒，天然是加鎖失敗了。

這只是舉個例子，實際上並不該該等每一個節點那麼長時間，就像官網所說的那樣，假設有效期是10秒，那麼單個redis實例操做超時時間，應該在5到50毫秒(注意時間單位)

仍是假設咱們設置有效期是30秒，圖中超時了兩個redis節點。 那麼加鎖成功的節點總共花費了3秒，因此鎖的實際有效期是小於27秒的。

即扣除加鎖成功三個實例的3秒，還要扣除等待超時redis實例的總共時間。

看到這，你有可能對這個算法有一些疑問，那麼你不是一我的。

回頭看看Redis官網關於紅鎖的描述

就在這篇描述頁面的最下面，你能看到著名的關於紅鎖的神仙打架事件。

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

官方掛人，最爲致命。

開個玩笑，要是質疑能被官方掛到官網，說明確定是有價值的。

因此說若是項目裏要使用紅鎖，除了紅鎖的介紹，不妨要多看兩篇文章，即：

1. Martin Kleppmann的質疑貼
2. antirez的反擊貼

總結

看了這麼多，是否是發現如何實現，都不能保證100%的穩定。

程序就是這樣，沒有絕對的穩定，因此作好人工補償環節也是重要的一環，畢竟：

技術不夠，人工來湊～

做者：Vt
連接：https://juejin.im/post/5e61a4... 來源：掘金 著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。