面試問題：Redis 分布式鎖的細(xì)節(jié)

正文如下

來源：juejin.im/post/5e61a454e51d4526f071e1df

• 序-碎碎叨叨
• 正文-開門見山
• setnx
• redisson
• RedLock
• 總結(jié)

序-碎碎叨叨

在家辦公的第N周，

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

不知道會(huì)不會(huì)落灰太嚴(yán)重，被保潔阿姨扔掉了。

筆者今天帶來一篇關(guān)于redis鎖的文章

連敲帶畫 碼出此文，有一些細(xì)節(jié)，對(duì)redis鎖不清晰的盆友不妨瞧一瞧。

如果是有經(jīng)驗(yàn)的盆友，挑挑毛病，那筆者是更感謝了～

閑話不多，馬上發(fā)車。

正文-開門見山

談起redis鎖，下面三個(gè)，算是出現(xiàn)最多的高頻詞匯：

• setnx
• redLock
• redisson

setnx

其實(shí)目前通常所說的setnx命令，并非單指redis的setnx key value這條命令。

一般代指redis中對(duì)set 命令加上nx 參數(shù)進(jìn)行使用，   set 這個(gè)命令，目前已經(jīng)支持這么多參數(shù)可選：

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

當(dāng)然了，就不在文章中默寫Api了，基礎(chǔ)參數(shù)還有不清晰的，可以蹦到官網(wǎng)。

上圖是筆者畫的setnx 大致原理，主要依托了它的key不存在才能set成功的特性 ，進(jìn)程A拿到鎖，在沒有刪除鎖的Key時(shí)，進(jìn)程B自然獲取鎖就失敗了。

那么為什么要使用PX 30000去設(shè)置一個(gè)超時(shí)時(shí)間？

是怕進(jìn)程A 不講道理啊，鎖沒等釋放呢，萬一崩了 ，直接原地把鎖帶走了，導(dǎo)致系統(tǒng)中誰也拿不到鎖。

就算這樣，還是不能保證萬無一失。

如果進(jìn)程A 又不講道理，操作鎖內(nèi)資源超過筆者設(shè)置的超時(shí)時(shí)間 ，那么就會(huì)導(dǎo)致其他進(jìn)程拿到鎖 ，等進(jìn)程A 回來了，回手就是把其他進(jìn)程的鎖刪了，如圖：

還是剛才那張圖，將T5 時(shí)刻改成了鎖超時(shí)，被redis釋放。

進(jìn)程B 在T6 開開心心拿到鎖不到一會(huì)，進(jìn)程A 操作完成，回手一個(gè)del ，就把鎖釋放了。

當(dāng)進(jìn)程B 操作完成，去釋放鎖的時(shí)候（圖中T8時(shí)刻）：

找不到鎖其實(shí)還算好的，萬一T7 時(shí)刻有個(gè)進(jìn)程C 過來加鎖成功，那么進(jìn)程B 就把進(jìn)程C 的鎖釋放了。以此類推，進(jìn)程C 可能釋放進(jìn)程D 的鎖，進(jìn)程D ....(禁止套娃)，具體什么后果就不得而知了。

所以在用setnx 的時(shí)候，key雖然是主要作用，但是value 也不能閑著，可以設(shè)置一個(gè)唯一的客戶端ID ，或者用UUID 這種隨機(jī)數(shù)。

當(dāng)解鎖的時(shí)候，先獲取value判斷是否是當(dāng)前進(jìn)程加的鎖，再去刪除。偽代碼 ：

String uuid = xxxx;
// 偽代碼，具體實(shí)現(xiàn)看項(xiàng)目中用的連接工具
// 有的提供的方法名為set 有的叫setIfAbsent
set Test uuid NX PX 3000
try{
// biz handle....
} finally {
    // unlock
    if(uuid.equals(redisTool.get('Test')){
        redisTool.del('Test');
    }
}

這回看起來是不是穩(wěn)了。

相反，這回的問題更明顯了，在finally代碼塊中，get和del并非原子操作 ，還是有進(jìn)程安全問題。

為什么有問題還說這么多呢？

第一，搞清劣勢所在，才能更好的完善。

第二點(diǎn)，其實(shí)上文中最后這段代碼，還是有很多公司在用 的。

大小項(xiàng)目悖論：大公司實(shí)現(xiàn)規(guī)范，但是小司小項(xiàng)目雖然存在不嚴(yán)謹(jǐn)，可并發(fā)倒也不高，出問題的概率和大公司一樣低。  -- 魯迅

那么刪除鎖的正確姿勢之一，就是可以使用lua 腳本，通過redis的eval /evalsha 命令來運(yùn)行：

-- lua刪除鎖：
-- KEYS和ARGV分別是以集合方式傳入的參數(shù)，對(duì)應(yīng)上文的Test和uuid。
-- 如果對(duì)應(yīng)的value等于傳入的uuid。
if redis.call('get', KEYS[1]) == ARGV[1]
    then
 -- 執(zhí)行刪除操作
        return redis.call('del', KEYS[1])
    else
 -- 不成功，返回0
        return 0
end

通過lua 腳本能保證原子性的原因說的通俗一點(diǎn)：

就算你在lua 里寫出花，執(zhí)行也是一個(gè)命令(eval /evalsha )去執(zhí)行的，一條命令沒執(zhí)行完，其他客戶端是看不到的。

那么既然這么麻煩，有沒有比較好的工具呢？就要說到redisson 了。

介紹redisson 之前，筆者簡單解釋一下為什么現(xiàn)在的setnx 默認(rèn)是指set 命令帶上nx 參數(shù)，而不是直接說是setnx 這個(gè)命令。

因?yàn)閞edis版本在2.6.12 之前，set是不支持nx參數(shù)的，如果想要完成一個(gè)鎖，那么需要兩條命令：

1. setnx Test uuid
2. expire Test 30

即放入Key和設(shè)置有效期，是分開的兩步，理論上會(huì)出現(xiàn)1 剛執(zhí)行完，程序掛掉，無法保證原子性。

但是早在2013年 ，也就是7年前，Redis就發(fā)布了2.6.12 版本，并且官網(wǎng)(set命令頁)，也早早就說明了“SETNX, SETEX, PSETEX可能在未來的版本中，會(huì)棄用并永久刪除 ”。

筆者曾閱讀過一位大佬的文章，其中就有一句指導(dǎo)入門者的面試小套路，具體文字忘記了，大概意思如下：

說到redis鎖的時(shí)候，可以先從setnx講起，最后慢慢引出set命令的可以加參數(shù)，可以體現(xiàn)出自己的知識(shí)面。

如果有緣你也閱讀過這篇文章，并且學(xué)到了這個(gè)套路，作為本文的筆者我要加一句提醒：

請(qǐng)注意你的工作年限！首先回答官網(wǎng)表明即將廢棄的命令，再引出set命令 七年前的“新特性”，如果是剛畢業(yè)不久的人這么說，面試官會(huì)以為自己穿越了。

你套路面試官，面試官也會(huì)套路你。  -- vt?沃茲基碩德

redisson

Redisson是java的redis客戶端之一 ，提供了一些api方便操作redis。

但是redisson這個(gè)客戶端可有點(diǎn)厲害，筆者在官網(wǎng)截了僅僅是一部分的圖：

這個(gè)特性列表可以說是太多了，是不是還看到了一些JUC 包下面的類名，redisson幫我們搞了分布式的版本，比如AtomicLong ，直接用RedissonAtomicLong 就行了，連類名都不用去新記，很人性化了。

鎖只是它的冰山一角，并且從它的wiki頁面看到，對(duì)主從，哨兵，集群等模式都支持，當(dāng)然了，單節(jié)點(diǎn)模式肯定是支持的。

本文還是以鎖為主，其他的不過多介紹。

Redisson普通的鎖實(shí)現(xiàn)源碼主要是RedissonLock 這個(gè)類，還沒有看過它源碼的盆友，不妨去瞧一瞧。

源碼中加鎖/釋放鎖 操作都是用lua 腳本完成的，封裝的非常完善，開箱即用。

這里有個(gè)小細(xì)節(jié)，加鎖使用setnx 就能實(shí)現(xiàn)，也采用lua 腳本是不是多此一舉？筆者也非常嚴(yán)謹(jǐn) 的思考了一下：這么厲害的東西哪能寫廢代碼？

其實(shí)筆者仔細(xì)看了一下，加鎖解鎖的lua腳本考慮的非常全面，其中就包括鎖的重入性 ，這點(diǎn)可以說是考慮非常周全，我也隨手寫了代碼測試一下：

的確用起來像jdk的ReentrantLock 一樣絲滑，那么redisson實(shí)現(xiàn)的已經(jīng)這么完善，redLock又是什么？

RedLock

redLock 的中文是直譯過來的，就叫紅鎖 。

紅鎖并非是一個(gè)工具，而是redis官方提出的一種分布式鎖的算法 。

就在剛剛介紹完的redisson中，就實(shí)現(xiàn)了redLock版本的鎖。也就是說除了getLock 方法，還有getRedLock 方法。

筆者大概畫了一下對(duì)紅鎖的理解：

如果你不熟悉redis高可用部署，那么沒關(guān)系。redLock算法雖然是需要多個(gè)實(shí)例，但是這些實(shí)例都是獨(dú)自部署的，沒有主從關(guān)系。

RedLock作者指出，之所以要用獨(dú)立的，是避免了redis異步復(fù)制造成的鎖丟失，比如：主節(jié)點(diǎn)沒來的及把剛剛set進(jìn)來這條數(shù)據(jù) 給從節(jié)點(diǎn)，就掛了。

有些人是不是覺得大佬們都是杠精啊，天天就想著極端情況。其實(shí)高可用 嘛，拼的就是99.999...% 中小數(shù)點(diǎn)后面的位數(shù)。

回到上面那張簡陋的圖片，紅鎖算法認(rèn)為，只要(N/2) + 1個(gè)節(jié)點(diǎn)加鎖成功，那么就認(rèn)為獲取了鎖， 解鎖時(shí)將所有實(shí)例解鎖。流程為：

1. 順序向五個(gè)節(jié)點(diǎn)請(qǐng)求加鎖
2. 根據(jù)一定的超時(shí)時(shí)間 來推斷是不是跳過該節(jié)點(diǎn)
3. 三個(gè)節(jié)點(diǎn)加鎖成功并且花費(fèi)時(shí)間小于鎖的有效期
4. 認(rèn)定加鎖成功

也就是說，假設(shè)鎖30秒 過期，三個(gè)節(jié)點(diǎn)加鎖花了31秒，自然是加鎖失敗了。

這只是舉個(gè)例子，實(shí)際上并不應(yīng)該等每個(gè)節(jié)點(diǎn)那么長時(shí)間，就像官網(wǎng)所說的那樣，假設(shè)有效期是10秒 ，那么單個(gè)redis實(shí)例操作超時(shí)時(shí)間，應(yīng)該在5到50毫秒 (注意時(shí)間單位)

還是假設(shè)我們?cè)O(shè)置有效期是30秒，圖中超時(shí)了兩個(gè)redis節(jié)點(diǎn)。那么加鎖成功的節(jié)點(diǎn)總共花費(fèi) 了3秒，所以鎖的實(shí)際有效期 是小于27秒的。

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

看到這，你有可能對(duì)這個(gè)算法有一些疑問，那么你不是一個(gè)人。

回頭看看Redis官網(wǎng)關(guān)于紅鎖的描述

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

即Martin Kleppmann和antirez的redLock辯論. 一個(gè)是很有資歷的分布式架構(gòu)師，一個(gè)是redis之父。

官方掛人，最為致命。

開個(gè)玩笑，要是質(zhì)疑能被官方掛到官網(wǎng)，說明肯定是有價(jià)值的。

所以說如果項(xiàng)目里要使用紅鎖，除了紅鎖的介紹，不妨要多看兩篇文章，即：

1. Martin Kleppmann的質(zhì)疑貼
2. antirez的反擊貼

總結(jié)

看了這么多，是不是發(fā)現(xiàn)如何實(shí)現(xiàn)，都不能保證100 %的穩(wěn)定。

程序就是這樣，沒有絕對(duì)的穩(wěn)定，所以做好人工補(bǔ)償 環(huán)節(jié)也是重要的一環(huán)，畢竟：

技術(shù)不夠，人工來湊～

點(diǎn)個(gè)在看結(jié)對(duì)編程一把