Redis 分布式鎖相關(guān)的話題褥琐，很多文章都已經(jīng)寫爛了妆够。

但我發(fā)現(xiàn)網(wǎng)上 99% 的文章传趾，并沒(méi)有把這個(gè) Redis 分布式鎖真正講清楚迎膜。導(dǎo)致很多人看了很多文章，依舊云里霧里墨缘。例如下面這些問(wèn)題：

• 基于 Redis 如何實(shí)現(xiàn)一個(gè)分布式鎖？
• Redis 分布式鎖真的安全嗎零抬？
• Redis 鎖改進(jìn)版的 Redlock 有什么問(wèn)題镊讼？一定安全嗎？
• 業(yè)界爭(zhēng)論 Redlock平夜，到底在爭(zhēng)論什么蝶棋？哪種觀點(diǎn)是對(duì)的？
• 分布式鎖到底用 Redis 還是 Zookeeper忽妒？
• 實(shí)現(xiàn)一個(gè)有「容錯(cuò)性」的分布式鎖玩裙，都需要考慮哪些問(wèn)題兼贸？

下面，我就來(lái)把這些問(wèn)題徹底講清楚吃溅。

讀完下面這些內(nèi)容溶诞，你不僅可以徹底了解分布式鎖，還會(huì)對(duì)「分布式系統(tǒng)」有更加深刻的理解决侈。

內(nèi)容稍微有點(diǎn)長(zhǎng)螺垢，但干貨很多，希望你可以耐心讀完赖歌。

image.png

為什么需要分布式鎖枉圃？

在開始講分布式鎖之前，有必要簡(jiǎn)單介紹一下庐冯，為什么需要分布式鎖孽亲？

與分布式鎖相對(duì)應(yīng)的是「單機(jī)鎖」，我們?cè)趯懚嗑€程程序時(shí)展父，避免同時(shí)操作一個(gè)共享變量產(chǎn)生數(shù)據(jù)問(wèn)題返劲，通常會(huì)使用一把鎖來(lái)「互斥」，以保證共享變量的正確性犯祠，其使用范圍是在「同一個(gè)進(jìn)程」中旭等。

如果換做是多個(gè)進(jìn)程，需要同時(shí)操作一個(gè)共享資源衡载，如何互斥呢搔耕？

例如，現(xiàn)在的業(yè)務(wù)應(yīng)用通常都是微服務(wù)架構(gòu)痰娱，這也意味著一個(gè)應(yīng)用會(huì)部署多個(gè)進(jìn)程弃榨，那這多個(gè)進(jìn)程如果需要修改 MySQL 中的同一行記錄時(shí)，為了避免操作亂序?qū)е聰?shù)據(jù)錯(cuò)誤梨睁，此時(shí)鲸睛，我們就需要引入「分布式鎖」來(lái)解決這個(gè)問(wèn)題了。

image.png

想要實(shí)現(xiàn)分布式鎖坡贺，必須借助一個(gè)外部系統(tǒng)官辈，所有進(jìn)程都去這個(gè)系統(tǒng)上申請(qǐng)「加鎖」。

而這個(gè)外部系統(tǒng)遍坟，必須要實(shí)現(xiàn)「互斥」的能力拳亿，即兩個(gè)請(qǐng)求同時(shí)進(jìn)來(lái)，只會(huì)給一個(gè)進(jìn)程返回成功愿伴，另一個(gè)返回失敺慰（或等待）。

這個(gè)外部系統(tǒng)隔节，可以是 MySQL鹅经，也可以是 Redis 或 Zookeeper寂呛。但為了追求更好的性能，我們通常會(huì)選擇使用 Redis 或 Zookeeper 來(lái)做瘾晃。

下面我就以 Redis 為主線贷痪，由淺入深，帶你深度剖析一下酗捌，分布式鎖的各種「安全性」問(wèn)題呢诬，幫你徹底理解分布式鎖。

分布式鎖怎么實(shí)現(xiàn)胖缤？

我們從最簡(jiǎn)單的開始講起尚镰。

想要實(shí)現(xiàn)分布式鎖，必須要求 Redis 有「互斥」的能力哪廓，我們可以使用 SETNX 命令狗唉，這個(gè)命令表示SET if Not eXists，即如果 key 不存在涡真，才會(huì)設(shè)置它的值分俯，否則什么也不做。

兩個(gè)客戶端進(jìn)程可以執(zhí)行這個(gè)命令哆料，達(dá)到互斥缸剪，就可以實(shí)現(xiàn)一個(gè)分布式鎖。

客戶端 1 申請(qǐng)加鎖东亦，加鎖成功：

127.0.0.1:6379> SETNX lock 1
(integer) 1     // 客戶端1杏节，加鎖成功

客戶端 2 申請(qǐng)加鎖，因?yàn)楹蟮竭_(dá)典阵，加鎖失敺苡妗：

127.0.0.1:6379> SETNX lock 1
(integer) 0     // 客戶端2，加鎖失敗

此時(shí)壮啊，加鎖成功的客戶端嫉鲸，就可以去操作「共享資源」，例如歹啼，修改 MySQL 的某一行數(shù)據(jù)玄渗，或者調(diào)用一個(gè) API 請(qǐng)求。

操作完成后狸眼，還要及時(shí)釋放鎖藤树，給后來(lái)者讓出操作共享資源的機(jī)會(huì)。如何釋放鎖呢份企？

也很簡(jiǎn)單也榄，直接使用 DEL 命令刪除這個(gè) key 即可：

127.0.0.1:6379> DEL lock // 釋放鎖
(integer) 1

這個(gè)邏輯非常簡(jiǎn)單巡莹，整體的路程就是這樣：

image.png

但是司志，它存在一個(gè)很大的問(wèn)題甜紫，當(dāng)客戶端 1 拿到鎖后，如果發(fā)生下面的場(chǎng)景骂远，就會(huì)造成「死鎖」：

1. 程序處理業(yè)務(wù)邏輯異常囚霸，沒(méi)及時(shí)釋放鎖
2. 進(jìn)程掛了，沒(méi)機(jī)會(huì)釋放鎖

這時(shí)激才，這個(gè)客戶端就會(huì)一直占用這個(gè)鎖拓型，而其它客戶端就「永遠(yuǎn)」拿不到這把鎖了。

怎么解決這個(gè)問(wèn)題呢瘸恼？

如何避免死鎖劣挫？

我們很容易想到的方案是，在申請(qǐng)鎖時(shí)东帅，給這把鎖設(shè)置一個(gè)「租期」压固。

在 Redis 中實(shí)現(xiàn)時(shí)，就是給這個(gè) key 設(shè)置一個(gè)「過(guò)期時(shí)間」靠闭。這里我們假設(shè)帐我，操作共享資源的時(shí)間不會(huì)超過(guò) 10s，那么在加鎖時(shí)愧膀，給這個(gè) key 設(shè)置 10s 過(guò)期即可：

127.0.0.1:6379> SETNX lock 1    // 加鎖
(integer) 1
127.0.0.1:6379> EXPIRE lock 10  // 10s后自動(dòng)過(guò)期
(integer) 1

這樣一來(lái)拦键，無(wú)論客戶端是否異常，這個(gè)鎖都可以在 10s 后被「自動(dòng)釋放」檩淋，其它客戶端依舊可以拿到鎖芬为。

但這樣真的沒(méi)問(wèn)題嗎？

還是有問(wèn)題狼钮。

現(xiàn)在的操作碳柱，加鎖、設(shè)置過(guò)期是 2 條命令熬芜，有沒(méi)有可能只執(zhí)行了第一條莲镣，第二條卻「來(lái)不及」執(zhí)行的情況發(fā)生呢？例如：

1. SETNX 執(zhí)行成功涎拉，執(zhí)行 EXPIRE 時(shí)由于網(wǎng)絡(luò)問(wèn)題瑞侮，執(zhí)行失敗
2. SETNX 執(zhí)行成功，Redis 異常宕機(jī)鼓拧，EXPIRE 沒(méi)有機(jī)會(huì)執(zhí)行
3. SETNX 執(zhí)行成功半火，客戶端異常崩潰，EXPIRE 也沒(méi)有機(jī)會(huì)執(zhí)行

總之季俩，這兩條命令不能保證是原子操作（一起成功）钮糖，就有潛在的風(fēng)險(xiǎn)導(dǎo)致過(guò)期時(shí)間設(shè)置失敗，依舊發(fā)生「死鎖」問(wèn)題。

怎么辦店归？

在 Redis 2.6.12 版本之前阎抒，我們需要想盡辦法，保證 SETNX 和 EXPIRE 原子性執(zhí)行消痛，還要考慮各種異常情況如何處理且叁。

但在 Redis 2.6.12 之后，Redis 擴(kuò)展了 SET 命令的參數(shù)秩伞，用這一條命令就可以了：

// 一條命令保證原子性執(zhí)行
127.0.0.1:6379> SET lock 1 EX 10 NX
OK

這樣就解決了死鎖問(wèn)題逞带，也比較簡(jiǎn)單。

我們?cè)賮?lái)看分析下纱新，它還有什么問(wèn)題展氓？

試想這樣一種場(chǎng)景：

1. 客戶端 1 加鎖成功，開始操作共享資源
2. 客戶端 1 操作共享資源的時(shí)間脸爱，「超過(guò)」了鎖的過(guò)期時(shí)間带饱，鎖被「自動(dòng)釋放」
3. 客戶端 2 加鎖成功，開始操作共享資源
4. 客戶端 1 操作共享資源完成阅羹，釋放鎖（但釋放的是客戶端 2 的鎖）

看到了么勺疼，這里存在兩個(gè)嚴(yán)重的問(wèn)題：

1. 鎖過(guò)期：客戶端 1 操作共享資源耗時(shí)太久，導(dǎo)致鎖被自動(dòng)釋放捏鱼，之后被客戶端 2 持有
2. 釋放別人的鎖：客戶端 1 操作共享資源完成后执庐，卻又釋放了客戶端 2 的鎖

導(dǎo)致這兩個(gè)問(wèn)題的原因是什么？我們一個(gè)個(gè)來(lái)看导梆。

第一個(gè)問(wèn)題轨淌，可能是我們?cè)u(píng)估操作共享資源的時(shí)間不準(zhǔn)確導(dǎo)致的。

例如看尼，操作共享資源的時(shí)間「最慢」可能需要 15s递鹉，而我們卻只設(shè)置了 10s 過(guò)期，那這就存在鎖提前過(guò)期的風(fēng)險(xiǎn)藏斩。

過(guò)期時(shí)間太短躏结，那增大冗余時(shí)間，例如設(shè)置過(guò)期時(shí)間為 20s狰域，這樣總可以了吧媳拴？

這樣確實(shí)可以「緩解」這個(gè)問(wèn)題，降低出問(wèn)題的概率兆览，但依舊無(wú)法「徹底解決」問(wèn)題屈溉。

為什么？

原因在于抬探，客戶端在拿到鎖之后子巾，在操作共享資源時(shí)，遇到的場(chǎng)景有可能是很復(fù)雜的，例如线梗，程序內(nèi)部發(fā)生異常匿醒、網(wǎng)絡(luò)請(qǐng)求超時(shí)等等。

既然是「預(yù)估」時(shí)間缠导，也只能是大致計(jì)算，除非你能預(yù)料并覆蓋到所有導(dǎo)致耗時(shí)變長(zhǎng)的場(chǎng)景溉痢，但這其實(shí)很難僻造。

有什么更好的解決方案嗎？

別急孩饼，關(guān)于這個(gè)問(wèn)題髓削，我會(huì)在后面詳細(xì)來(lái)講對(duì)應(yīng)的解決方案。

我們繼續(xù)來(lái)看第二個(gè)問(wèn)題镀娶。

第二個(gè)問(wèn)題在于立膛，一個(gè)客戶端釋放了其它客戶端持有的鎖。

想一下梯码，導(dǎo)致這個(gè)問(wèn)題的關(guān)鍵點(diǎn)在哪宝泵？

重點(diǎn)在于，每個(gè)客戶端在釋放鎖時(shí)轩娶，都是「無(wú)腦」操作儿奶，并沒(méi)有檢查這把鎖是否還「歸自己持有」，所以就會(huì)發(fā)生釋放別人鎖的風(fēng)險(xiǎn)鳄抒，這樣的解鎖流程闯捎，很不「嚴(yán)謹(jǐn)」！

如何解決這個(gè)問(wèn)題呢许溅？

鎖被別人釋放怎么辦?

解決辦法是：客戶端在加鎖時(shí)瓤鼻，設(shè)置一個(gè)只有自己知道的「唯一標(biāo)識(shí)」進(jìn)去。

例如贤重，可以是自己的線程 ID茬祷，也可以是一個(gè) UUID（隨機(jī)且唯一），這里我們以 UUID 舉例：

// 鎖的VALUE設(shè)置為UUID
127.0.0.1:6379> SET lock $uuid EX 20 NX
OK

這里假設(shè) 20s 操作共享時(shí)間完全足夠并蝗，先不考慮鎖自動(dòng)過(guò)期的問(wèn)題牲迫。

之后，在釋放鎖時(shí)借卧，要先判斷這把鎖是否還歸自己持有盹憎，偽代碼可以這么寫：

// 鎖是自己的，才釋放
if redis.get("lock") == $uuid:
    redis.del("lock")

這里釋放鎖使用的是 GET + DEL 兩條命令铐刘，這時(shí)陪每，又會(huì)遇到我們前面講的原子性問(wèn)題了。

1. 客戶端 1 執(zhí)行 GET，判斷鎖是自己的
2. 客戶端 2 執(zhí)行了 SET 命令檩禾，強(qiáng)制獲取到鎖（雖然發(fā)生概率比較低挂签，但我們需要嚴(yán)謹(jǐn)?shù)乜紤]鎖的安全性模型）
3. 客戶端 1 執(zhí)行 DEL，卻釋放了客戶端 2 的鎖

由此可見盼产，這兩個(gè)命令還是必須要原子執(zhí)行才行饵婆。

怎樣原子執(zhí)行呢？Lua 腳本戏售。

我們可以把這個(gè)邏輯侨核，寫成 Lua 腳本，讓 Redis 來(lái)執(zhí)行灌灾。

因?yàn)?Redis 處理每一個(gè)請(qǐng)求是「單線程」執(zhí)行的搓译，在執(zhí)行一個(gè) Lua 腳本時(shí)，其它請(qǐng)求必須等待锋喜，直到這個(gè) Lua 腳本處理完成些己，這樣一來(lái)，GET + DEL 之間就不會(huì)插入其它命令了嘿般。

安全釋放鎖的 Lua 腳本如下：

// 判斷鎖是自己的段标，才釋放
if redis.call("GET",KEYS[1]) == ARGV[1]
then
    return redis.call("DEL",KEYS[1])
else
    return 0
end

好了，這樣一路優(yōu)化炉奴，整個(gè)的加鎖怀樟、解鎖的流程就更「嚴(yán)謹(jǐn)」了。

這里我們先小結(jié)一下盆佣，基于 Redis 實(shí)現(xiàn)的分布式鎖往堡，一個(gè)嚴(yán)謹(jǐn)?shù)牡牧鞒倘缦拢?/p>

1. 加鎖：SET unique_id EX $expire_time NX
2. 操作共享資源
3. 釋放鎖：Lua 腳本，先 GET 判斷鎖是否歸屬自己共耍，再 DEL 釋放鎖

image.png

好虑灰，有了這個(gè)完整的鎖模型，讓我們重新回到前面提到的第一個(gè)問(wèn)題痹兜。

鎖過(guò)期時(shí)間不好評(píng)估怎么辦穆咐？

鎖過(guò)期時(shí)間不好評(píng)估怎么辦？

前面我們提到字旭，鎖的過(guò)期時(shí)間如果評(píng)估不好对湃，這個(gè)鎖就會(huì)有「提前」過(guò)期的風(fēng)險(xiǎn)。

當(dāng)時(shí)給的妥協(xié)方案是遗淳，盡量「冗余」過(guò)期時(shí)間拍柒，降低鎖提前過(guò)期的概率。

這個(gè)方案其實(shí)也不能完美解決問(wèn)題屈暗，那怎么辦呢拆讯？

是否可以設(shè)計(jì)這樣的方案：加鎖時(shí)脂男，先設(shè)置一個(gè)過(guò)期時(shí)間，然后我們開啟一個(gè)「守護(hù)線程」种呐，定時(shí)去檢測(cè)這個(gè)鎖的失效時(shí)間宰翅，如果鎖快要過(guò)期了，操作共享資源還未完成爽室，那么就自動(dòng)對(duì)鎖進(jìn)行「續(xù)期」汁讼，重新設(shè)置過(guò)期時(shí)間。

這確實(shí)一種比較好的方案阔墩。

如果你是 Java 技術(shù)棧嘿架，幸運(yùn)的是，已經(jīng)有一個(gè)庫(kù)把這些工作都封裝好了：Redisson戈擒。

Redisson 是一個(gè) Java 語(yǔ)言實(shí)現(xiàn)的 Redis SDK 客戶端，在使用分布式鎖時(shí)艰毒，它就采用了「自動(dòng)續(xù)期」的方案來(lái)避免鎖過(guò)期筐高，這個(gè)守護(hù)線程我們一般也把它叫做「看門狗」線程。

image.png

除此之外丑瞧，這個(gè) SDK 還封裝了很多易用的功能：

• 可重入鎖
• 樂(lè)觀鎖
• 公平鎖
• 讀寫鎖
• Redlock（紅鎖柑土，下面會(huì)詳細(xì)講）

這個(gè) SDK 提供的 API 非常友好，它可以像操作本地鎖的方式绊汹，操作分布式鎖稽屏。如果你是 Java 技術(shù)棧，可以直接把它用起來(lái)西乖。

這里不重點(diǎn)介紹 Redisson 的使用狐榔，大家可以看官方 Github 學(xué)習(xí)如何使用，比較簡(jiǎn)單获雕。

到這里我們?cè)傩〗Y(jié)一下薄腻，基于 Redis 的實(shí)現(xiàn)分布式鎖，前面遇到的問(wèn)題届案，以及對(duì)應(yīng)的解決方案：

• 死鎖：設(shè)置過(guò)期時(shí)間
• 過(guò)期時(shí)間評(píng)估不好庵楷，鎖提前過(guò)期：守護(hù)線程，自動(dòng)續(xù)期
• 鎖被別人釋放：鎖寫入唯一標(biāo)識(shí)楣颠，釋放鎖先檢查標(biāo)識(shí)尽纽，再釋放

還有哪些問(wèn)題場(chǎng)景，會(huì)危害 Redis 鎖的安全性呢童漩？

之前分析的場(chǎng)景都是弄贿，鎖在「單個(gè)」Redis 實(shí)例中可能產(chǎn)生的問(wèn)題，并沒(méi)有涉及到 Redis 的部署架構(gòu)細(xì)節(jié)矫膨。

而我們?cè)谑褂?Redis 時(shí)挎春，一般會(huì)采用主從集群 + 哨兵的模式部署看疙，這樣做的好處在于，當(dāng)主庫(kù)異常宕機(jī)時(shí)直奋，哨兵可以實(shí)現(xiàn)「故障自動(dòng)切換」能庆，把從庫(kù)提升為主庫(kù)，繼續(xù)提供服務(wù)脚线，以此保證可用性搁胆。

那當(dāng)「主從發(fā)生切換」時(shí)，這個(gè)分布鎖會(huì)依舊安全嗎邮绿？

試想這樣的場(chǎng)景：

1. 客戶端 1 在主庫(kù)上執(zhí)行 SET 命令渠旁，加鎖成功
2. 此時(shí)，主庫(kù)異常宕機(jī)船逮，SET 命令還未同步到從庫(kù)上（主從復(fù)制是異步的）
3. 從庫(kù)被哨兵提升為新主庫(kù)顾腊，這個(gè)鎖在新的主庫(kù)上，丟失了挖胃！

可見杂靶，當(dāng)引入 Redis 副本后，分布鎖還是可能會(huì)受到影響酱鸭。

怎么解決這個(gè)問(wèn)題吗垮？

為此，Redis 的作者提出一種解決方案凹髓，就是我們經(jīng)常聽到的 Redlock（紅鎖）烁登。

它真的可以解決上面這個(gè)問(wèn)題嗎？

Redlock 真的安全嗎蔚舀？

好饵沧，終于到了重頭戲。岸奶伞捷泞？上面講的那么多問(wèn)題，難道只是基礎(chǔ)寿谴？

是的锁右，那些只是開胃菜，真正的硬菜讶泰，從這里剛剛開始咏瑟。

如果上面講的內(nèi)容，你還沒(méi)有理解痪署，我建議你重新閱讀一遍码泞，先理清整個(gè)加鎖、解鎖的基本流程狼犯。

如果你已經(jīng)對(duì) Redlock 有所了解余寥，這里可以跟著我再?gòu)?fù)習(xí)一遍领铐，如果你不了解 Redlock，沒(méi)關(guān)系宋舷，我會(huì)帶你重新認(rèn)識(shí)它腌零。

值得提醒你的是隙赁，后面我不僅僅是講 Redlock 的原理，還會(huì)引出有關(guān)「分布式系統(tǒng)」中的很多問(wèn)題，你最好跟緊我的思路阎姥，在腦中一起分析問(wèn)題的答案箍土。

現(xiàn)在我們來(lái)看灌侣，Redis 作者提出的 Redlock 方案侥涵，是如何解決主從切換后，鎖失效問(wèn)題的儡嘶。

Redlock 的方案基于 2 個(gè)前提：

1. 不再需要部署從庫(kù)和哨兵實(shí)例喇聊，只部署主庫(kù)
2. 但主庫(kù)要部署多個(gè)，官方推薦至少 5 個(gè)實(shí)例

也就是說(shuō)蹦狂，想用使用 Redlock誓篱，你至少要部署 5 個(gè) Redis 實(shí)例，而且都是主庫(kù)鸥咖，它們之間沒(méi)有任何關(guān)系燕鸽，都是一個(gè)個(gè)孤立的實(shí)例兄世。

注意：不是部署 Redis Cluster啼辣，就是部署 5 個(gè)簡(jiǎn)單的 Redis 實(shí)例。

image.png

Redlock 具體如何使用呢御滩？

整體的流程是這樣的鸥拧，一共分為 5 步：

1. 客戶端先獲取「當(dāng)前時(shí)間戳T1」
2. 客戶端依次向這 5 個(gè) Redis 實(shí)例發(fā)起加鎖請(qǐng)求（用前面講到的 SET 命令），且每個(gè)請(qǐng)求會(huì)設(shè)置超時(shí)時(shí)間（毫秒級(jí)削解，要遠(yuǎn)小于鎖的有效時(shí)間）富弦，如果某一個(gè)實(shí)例加鎖失敗（包括網(wǎng)絡(luò)超時(shí)氛驮、鎖被其它人持有等各種異常情況）腕柜，就立即向下一個(gè) Redis 實(shí)例申請(qǐng)加鎖
3. 如果客戶端從 >=3 個(gè)（大多數(shù)）以上 Redis 實(shí)例加鎖成功，則再次獲取「當(dāng)前時(shí)間戳T2」矫废，如果 T2 - T1 < 鎖的過(guò)期時(shí)間盏缤，此時(shí)，認(rèn)為客戶端加鎖成功蓖扑，否則認(rèn)為加鎖失敗
4. 加鎖成功唉铜，去操作共享資源（例如修改 MySQL 某一行，或發(fā)起一個(gè) API 請(qǐng)求）
5. 加鎖失敗律杠，向「全部節(jié)點(diǎn)」發(fā)起釋放鎖請(qǐng)求（前面講到的 Lua 腳本釋放鎖）

我簡(jiǎn)單幫你總結(jié)一下潭流，有 4 個(gè)重點(diǎn)：

1. 客戶端在多個(gè) Redis 實(shí)例上申請(qǐng)加鎖
2. 必須保證大多數(shù)節(jié)點(diǎn)加鎖成功
3. 大多數(shù)節(jié)點(diǎn)加鎖的總耗時(shí)竞惋，要小于鎖設(shè)置的過(guò)期時(shí)間
4. 釋放鎖，要向全部節(jié)點(diǎn)發(fā)起釋放鎖請(qǐng)求

第一次看可能不太容易理解灰嫉，建議你把上面的文字多看幾遍拆宛，加深記憶。
然后熬甫，記住這 5 步胰挑，非常重要，下面會(huì)根據(jù)這個(gè)流程椿肩，剖析各種可能導(dǎo)致鎖失效的問(wèn)題假設(shè)瞻颂。

好，明白了 Redlock 的流程郑象，我們來(lái)看 Redlock 為什么要這么做贡这。

1) 為什么要在多個(gè)實(shí)例上加鎖？

本質(zhì)上是為了「容錯(cuò)」厂榛，部分實(shí)例異常宕機(jī)盖矫，剩余的實(shí)例加鎖成功，整個(gè)鎖服務(wù)依舊可用击奶。

2) 為什么大多數(shù)加鎖成功辈双，才算成功？

多個(gè) Redis 實(shí)例一起來(lái)用柜砾，其實(shí)就組成了一個(gè)「分布式系統(tǒng)」湃望。

在分布式系統(tǒng)中，總會(huì)出現(xiàn)「異常節(jié)點(diǎn)」痰驱，所以证芭，在談?wù)摲植际较到y(tǒng)問(wèn)題時(shí)，需要考慮異常節(jié)點(diǎn)達(dá)到多少個(gè)担映，也依舊不會(huì)影響整個(gè)系統(tǒng)的「正確性」废士。

這是一個(gè)分布式系統(tǒng)「容錯(cuò)」問(wèn)題，這個(gè)問(wèn)題的結(jié)論是：如果只存在「故障」節(jié)點(diǎn)蝇完，只要大多數(shù)節(jié)點(diǎn)正常官硝，那么整個(gè)系統(tǒng)依舊是可以提供正確服務(wù)的。

這個(gè)問(wèn)題的模型短蜕，就是我們經(jīng)常聽到的「拜占庭將軍」問(wèn)題氢架，感興趣可以去看算法的推演過(guò)程。

3) 為什么步驟 3 加鎖成功后忿危，還要計(jì)算加鎖的累計(jì)耗時(shí)达箍？

因?yàn)椴僮鞯氖嵌鄠€(gè)節(jié)點(diǎn)，所以耗時(shí)肯定會(huì)比操作單個(gè)實(shí)例耗時(shí)更久铺厨，而且缎玫，因?yàn)槭蔷W(wǎng)絡(luò)請(qǐng)求硬纤，網(wǎng)絡(luò)情況是復(fù)雜的，有可能存在延遲赃磨、丟包筝家、超時(shí)等情況發(fā)生，網(wǎng)絡(luò)請(qǐng)求越多邻辉，異常發(fā)生的概率就越大溪王。

所以，即使大多數(shù)節(jié)點(diǎn)加鎖成功值骇，但如果加鎖的累計(jì)耗時(shí)已經(jīng)「超過(guò)」了鎖的過(guò)期時(shí)間莹菱，那此時(shí)有些實(shí)例上的鎖可能已經(jīng)失效了，這個(gè)鎖就沒(méi)有意義了吱瘩。

4) 為什么釋放鎖道伟，要操作所有節(jié)點(diǎn)？

在某一個(gè) Redis 節(jié)點(diǎn)加鎖時(shí)使碾，可能因?yàn)椤妇W(wǎng)絡(luò)原因」導(dǎo)致加鎖失敗蜜徽。

例如，客戶端在一個(gè) Redis 實(shí)例上加鎖成功票摇，但在讀取響應(yīng)結(jié)果時(shí)拘鞋，網(wǎng)絡(luò)問(wèn)題導(dǎo)致讀取失敗，那這把鎖其實(shí)已經(jīng)在 Redis 上加鎖成功了矢门。

所以盆色，釋放鎖時(shí)，不管之前有沒(méi)有加鎖成功颅和，需要釋放「所有節(jié)點(diǎn)」的鎖傅事，以保證清理節(jié)點(diǎn)上「殘留」的鎖缕允。

好了峡扩，明白了 Redlock 的流程和相關(guān)問(wèn)題，看似 Redlock 確實(shí)解決了 Redis 節(jié)點(diǎn)異常宕機(jī)鎖失效的問(wèn)題障本，保證了鎖的「安全性」教届。

但事實(shí)真的如此嗎？

Redlock 的爭(zhēng)論誰(shuí)對(duì)誰(shuí)錯(cuò)驾霜？

Redis 作者把這個(gè)方案一經(jīng)提出案训，就馬上受到業(yè)界著名的分布式系統(tǒng)專家的質(zhì)疑！

這個(gè)專家叫 Martin粪糙，是英國(guó)劍橋大學(xué)的一名分布式系統(tǒng)研究員强霎。在此之前他曾是軟件工程師和企業(yè)家，從事大規(guī)模數(shù)據(jù)基礎(chǔ)設(shè)施相關(guān)的工作蓉冈。它還經(jīng)常在大會(huì)做演講城舞，寫博客轩触，寫書，也是開源貢獻(xiàn)者家夺。

他馬上寫了篇文章脱柱，質(zhì)疑這個(gè) Redlock 的算法模型是有問(wèn)題的，并對(duì)分布式鎖的設(shè)計(jì)拉馋，提出了自己的看法榨为。

之后，Redis 作者 Antirez 面對(duì)質(zhì)疑煌茴，不甘示弱随闺，也寫了一篇文章，反駁了對(duì)方的觀點(diǎn)蔓腐，并詳細(xì)剖析了 Redlock 算法模型的更多設(shè)計(jì)細(xì)節(jié)板壮。

而且，關(guān)于這個(gè)問(wèn)題的爭(zhēng)論合住，在當(dāng)時(shí)互聯(lián)網(wǎng)上也引起了非常激烈的討論绰精。

二人思路清晰，論據(jù)充分透葛，這是一場(chǎng)高手過(guò)招笨使，也是分布式系統(tǒng)領(lǐng)域非常好的一次思想的碰撞！雙方都是分布式系統(tǒng)領(lǐng)域的專家僚害，卻對(duì)同一個(gè)問(wèn)題提出很多相反的論斷硫椰，究竟是怎么回事？

下面我會(huì)從他們的爭(zhēng)論文章中萨蚕，提取重要的觀點(diǎn)靶草，整理呈現(xiàn)給你。

提醒：后面的信息量極大岳遥，可能不宜理解奕翔，最好放慢速度閱讀。

分布式專家 Martin 對(duì)于 Redlock 的質(zhì)疑

在他的文章中浩蓉，主要闡述了 4 個(gè)論點(diǎn)：

1) 分布式鎖的目的是什么派继？

Martin 表示，你必須先清楚你在使用分布式鎖的目的是什么捻艳？

他認(rèn)為有兩個(gè)目的驾窟。

第一，效率认轨。

使用分布式鎖的互斥能力绅络，是避免不必要地做同樣的兩次工作（例如一些昂貴的計(jì)算任務(wù)）。如果鎖失效，并不會(huì)帶來(lái)「惡性」的后果恩急，例如發(fā)了 2 次郵件等节视，無(wú)傷大雅。

第二假栓，正確性寻行。

使用鎖用來(lái)防止并發(fā)進(jìn)程互相干擾。如果鎖失效匾荆，會(huì)造成多個(gè)進(jìn)程同時(shí)操作同一條數(shù)據(jù)拌蜘，產(chǎn)生的后果是數(shù)據(jù)嚴(yán)重錯(cuò)誤、永久性不一致牙丽、數(shù)據(jù)丟失等惡性問(wèn)題简卧，就像給患者服用重復(fù)劑量的藥物一樣，后果嚴(yán)重烤芦。

他認(rèn)為举娩，如果你是為了前者——效率，那么使用單機(jī)版 Redis 就可以了构罗，即使偶爾發(fā)生鎖失效（宕機(jī)铜涉、主從切換），都不會(huì)產(chǎn)生嚴(yán)重的后果遂唧。而使用 Redlock 太重了芙代，沒(méi)必要。

而如果是為了正確性盖彭，Martin 認(rèn)為 Redlock 根本達(dá)不到安全性的要求纹烹，也依舊存在鎖失效的問(wèn)題！

2) 鎖在分布式系統(tǒng)中會(huì)遇到的問(wèn)題

Martin 表示召边，一個(gè)分布式系統(tǒng)铺呵，更像一個(gè)復(fù)雜的「野獸」，存在著你想不到的各種異常情況隧熙。

這些異常場(chǎng)景主要包括三大塊片挂，這也是分布式系統(tǒng)會(huì)遇到的三座大山：NPC。

• N：Network Delay贱鼻，網(wǎng)絡(luò)延遲
• P：Process Pause宴卖，進(jìn)程暫停（GC）
• C：Clock Drift滋将，時(shí)鐘漂移

Martin 用一個(gè)進(jìn)程暫停（GC）的例子邻悬，指出了 Redlock 安全性問(wèn)題：

1. 客戶端 1 請(qǐng)求鎖定節(jié)點(diǎn) A、B随闽、C父丰、D、E
2. 客戶端 1 的拿到鎖后，進(jìn)入 GC（時(shí)間比較久）
3. 所有 Redis 節(jié)點(diǎn)上的鎖都過(guò)期了
4. 客戶端 2 獲取到了 A蛾扇、B攘烛、C、D镀首、E 上的鎖
5. 客戶端 1 GC 結(jié)束坟漱，認(rèn)為成功獲取鎖
6. 客戶端 2 也認(rèn)為獲取到了鎖，發(fā)生「沖突」

Martin 認(rèn)為更哄，GC 可能發(fā)生在程序的任意時(shí)刻芋齿，而且執(zhí)行時(shí)間是不可控的。

注：當(dāng)然成翩，即使是使用沒(méi)有 GC 的編程語(yǔ)言觅捆，在發(fā)生網(wǎng)絡(luò)延遲、時(shí)鐘漂移時(shí)麻敌，也都有可能導(dǎo)致 Redlock 出現(xiàn)問(wèn)題栅炒，這里 Martin 只是拿 GC 舉例。

3) 假設(shè)時(shí)鐘正確的是不合理的

又或者术羔，當(dāng)多個(gè) Redis 節(jié)點(diǎn)「時(shí)鐘」發(fā)生問(wèn)題時(shí)赢赊，也會(huì)導(dǎo)致 Redlock 鎖失效。

1. 客戶端 1 獲取節(jié)點(diǎn) A级历、B域携、C 上的鎖，但由于網(wǎng)絡(luò)問(wèn)題鱼喉，無(wú)法訪問(wèn) D 和 E
2. 節(jié)點(diǎn) C 上的時(shí)鐘「向前跳躍」秀鞭，導(dǎo)致鎖到期
3. 客戶端 2 獲取節(jié)點(diǎn) C、D扛禽、E 上的鎖锋边，由于網(wǎng)絡(luò)問(wèn)題，無(wú)法訪問(wèn) A 和 B
4. 客戶端 1 和 2 現(xiàn)在都相信它們持有了鎖（沖突）

Martin 覺(jué)得编曼，Redlock 必須「強(qiáng)依賴」多個(gè)節(jié)點(diǎn)的時(shí)鐘是保持同步的豆巨，一旦有節(jié)點(diǎn)時(shí)鐘發(fā)生錯(cuò)誤，那這個(gè)算法模型就失效了掐场。

即使 C 不是時(shí)鐘跳躍往扔，而是「崩潰后立即重啟」，也會(huì)發(fā)生類似的問(wèn)題熊户。

Martin 繼續(xù)闡述萍膛，機(jī)器的時(shí)鐘發(fā)生錯(cuò)誤，是很有可能發(fā)生的：

• 系統(tǒng)管理員「手動(dòng)修改」了機(jī)器時(shí)鐘
• 機(jī)器時(shí)鐘在同步 NTP 時(shí)間時(shí)嚷堡，發(fā)生了大的「跳躍」

總之蝗罗，Martin 認(rèn)為，Redlock 的算法是建立在「同步模型」基礎(chǔ)上的，有大量資料研究表明串塑，同步模型的假設(shè)沼琉，在分布式系統(tǒng)中是有問(wèn)題的。

在混亂的分布式系統(tǒng)的中桩匪，你不能假設(shè)系統(tǒng)時(shí)鐘就是對(duì)的打瘪，所以，你必須非常小心你的假設(shè)傻昙。

4) 提出 fencing token 的方案瑟慈，保證正確性

相對(duì)應(yīng)的，Martin 提出一種被叫作 fencing token 的方案屋匕，保證分布式鎖的正確性葛碧。

這個(gè)模型流程如下：

1. 客戶端在獲取鎖時(shí)，鎖服務(wù)可以提供一個(gè)「遞增」的 token
2. 客戶端拿著這個(gè) token 去操作共享資源
3. 共享資源可以根據(jù) token 拒絕「后來(lái)者」的請(qǐng)求

image.png

這樣一來(lái)过吻，無(wú)論 NPC 哪種異常情況發(fā)生进泼，都可以保證分布式鎖的安全性，因?yàn)樗墙⒃凇府惒侥Ｐ汀股系摹?/p>

而 Redlock 無(wú)法提供類似 fencing token 的方案纤虽，所以它無(wú)法保證安全性乳绕。

他還表示，一個(gè)好的分布式鎖逼纸，無(wú)論 NPC 怎么發(fā)生洋措，可以不在規(guī)定時(shí)間內(nèi)給出結(jié)果，但并不會(huì)給出一個(gè)錯(cuò)誤的結(jié)果杰刽。也就是只會(huì)影響到鎖的「性能」（或稱之為活性）菠发，而不會(huì)影響它的「正確性」。

Martin 的結(jié)論：

1贺嫂、Redlock 不倫不類：它對(duì)于效率來(lái)講滓鸠，Redlock 比較重，沒(méi)必要這么做第喳，而對(duì)于正確性來(lái)說(shuō)糜俗，Redlock 是不夠安全的。

2曲饱、時(shí)鐘假設(shè)不合理：該算法對(duì)系統(tǒng)時(shí)鐘做出了危險(xiǎn)的假設(shè)（假設(shè)多個(gè)節(jié)點(diǎn)機(jī)器時(shí)鐘都是一致的）悠抹，如果不滿足這些假設(shè)，鎖就會(huì)失效扩淀。

3楔敌、無(wú)法保證正確性：Redlock 不能提供類似 fencing token 的方案，所以解決不了正確性的問(wèn)題引矩。為了正確性梁丘，請(qǐng)使用有「共識(shí)系統(tǒng)」的軟件侵浸，例如 Zookeeper旺韭。

好了氛谜，以上就是 Martin 反對(duì)使用 Redlock 的觀點(diǎn)，看起來(lái)有理有據(jù)区端。

下面我們來(lái)看 Redis 作者 Antirez 是如何反駁的值漫。

Redis 作者 Antirez 的反駁

在 Redis 作者的文章中，重點(diǎn)有 3 個(gè)：

1) 解釋時(shí)鐘問(wèn)題

首先织盼，Redis 作者一眼就看穿了對(duì)方提出的最為核心的問(wèn)題：時(shí)鐘問(wèn)題杨何。

Redis 作者表示，Redlock 并不需要完全一致的時(shí)鐘沥邻，只需要大體一致就可以了危虱，允許有「誤差」。

例如要計(jì)時(shí) 5s唐全，但實(shí)際可能記了 4.5s埃跷，之后又記了 5.5s，有一定誤差邮利，但只要不超過(guò)「誤差范圍」鎖失效時(shí)間即可弥雹，這種對(duì)于時(shí)鐘的精度的要求并不是很高，而且這也符合現(xiàn)實(shí)環(huán)境延届。

對(duì)于對(duì)方提到的「時(shí)鐘修改」問(wèn)題剪勿，Redis 作者反駁到：

1. 手動(dòng)修改時(shí)鐘：不要這么做就好了，否則你直接修改 Raft 日志方庭，那 Raft 也會(huì)無(wú)法工作...
2. 時(shí)鐘跳躍：通過(guò)「恰當(dāng)?shù)倪\(yùn)維」厕吉，保證機(jī)器時(shí)鐘不會(huì)大幅度跳躍（每次通過(guò)微小的調(diào)整來(lái)完成），實(shí)際上這是可以做到的

為什么 Redis 作者優(yōu)先解釋時(shí)鐘問(wèn)題械念？因?yàn)樵诤竺娴姆瘩g過(guò)程中赴涵，需要依賴這個(gè)基礎(chǔ)做進(jìn)一步解釋。

2) 解釋網(wǎng)絡(luò)延遲订讼、GC 問(wèn)題

之后髓窜，Redis 作者對(duì)于對(duì)方提出的，網(wǎng)絡(luò)延遲欺殿、進(jìn)程 GC 可能導(dǎo)致 Redlock 失效的問(wèn)題寄纵，也做了反駁：

我們重新回顧一下，Martin 提出的問(wèn)題假設(shè)：

1. 客戶端 1 請(qǐng)求鎖定節(jié)點(diǎn) A脖苏、B程拭、C、D棍潘、E
2. 客戶端 1 的拿到鎖后恃鞋，進(jìn)入 GC
3. 所有 Redis 節(jié)點(diǎn)上的鎖都過(guò)期了
4. 客戶端 2 獲取節(jié)點(diǎn) A崖媚、B、C恤浪、D畅哑、E 上的鎖
5. 客戶端 1 GC 結(jié)束，認(rèn)為成功獲取鎖
6. 客戶端 2 也認(rèn)為獲取到鎖水由，發(fā)生「沖突」

image.png

Redis 作者反駁到荠呐，這個(gè)假設(shè)其實(shí)是有問(wèn)題的，Redlock 是可以保證鎖安全的砂客。

這是怎么回事呢泥张？

還記得前面介紹 Redlock 流程的那 5 步嗎？這里我再拿過(guò)來(lái)讓你復(fù)習(xí)一下鞠值。

1. 客戶端先獲取「當(dāng)前時(shí)間戳T1」
2. 客戶端依次向這 5 個(gè) Redis 實(shí)例發(fā)起加鎖請(qǐng)求（用前面講到的 SET 命令）媚创，且每個(gè)請(qǐng)求會(huì)設(shè)置超時(shí)時(shí)間（毫秒級(jí)，要遠(yuǎn)小于鎖的有效時(shí)間）彤恶，如果某一個(gè)實(shí)例加鎖失敵啤（包括網(wǎng)絡(luò)超時(shí)、鎖被其它人持有等各種異常情況）粤剧，就立即向下一個(gè) Redis 實(shí)例申請(qǐng)加鎖
3. 如果客戶端從 3 個(gè)（大多數(shù)）以上 Redis 實(shí)例加鎖成功歇竟，則再次獲取「當(dāng)前時(shí)間戳T2」，如果 T2 - T1 < 鎖的過(guò)期時(shí)間抵恋，此時(shí)焕议，認(rèn)為客戶端加鎖成功，否則認(rèn)為加鎖失敗
4. 加鎖成功弧关，去操作共享資源（例如修改 MySQL 某一行盅安，或發(fā)起一個(gè) API 請(qǐng)求）
5. 加鎖失敗，向「全部節(jié)點(diǎn)」發(fā)起釋放鎖請(qǐng)求（前面講到的 Lua 腳本釋放鎖）

注意世囊，重點(diǎn)是 1-3别瞭，在步驟 3，加鎖成功后為什么要重新獲取「當(dāng)前時(shí)間戳T2」株憾？還用 T2 - T1 的時(shí)間蝙寨，與鎖的過(guò)期時(shí)間做比較？

Redis 作者強(qiáng)調(diào)：如果在 1-3 發(fā)生了網(wǎng)絡(luò)延遲嗤瞎、進(jìn)程 GC 等耗時(shí)長(zhǎng)的異常情況墙歪，那在第 3 步 T2 - T1，是可以檢測(cè)出來(lái)的贝奇，如果超出了鎖設(shè)置的過(guò)期時(shí)間虹菲，那這時(shí)就認(rèn)為加鎖會(huì)失敗，之后釋放所有節(jié)點(diǎn)的鎖就好了掉瞳！

Redis 作者繼續(xù)論述毕源，如果對(duì)方認(rèn)為浪漠，發(fā)生網(wǎng)絡(luò)延遲、進(jìn)程 GC 是在步驟 3 之后霎褐，也就是客戶端確認(rèn)拿到了鎖址愿，去操作共享資源的途中發(fā)生了問(wèn)題，導(dǎo)致鎖失效瘩欺，那這不止是 Redlock 的問(wèn)題必盖，任何其它鎖服務(wù)例如 Zookeeper拌牲，都有類似的問(wèn)題俱饿，這不在討論范疇內(nèi)。

這里我舉個(gè)例子解釋一下這個(gè)問(wèn)題：

1. 客戶端通過(guò) Redlock 成功獲取到鎖（通過(guò)了大多數(shù)節(jié)點(diǎn)加鎖成功塌忽、加鎖耗時(shí)檢查邏輯）
2. 客戶端開始操作共享資源拍埠，此時(shí)發(fā)生網(wǎng)絡(luò)延遲、進(jìn)程 GC 等耗時(shí)很長(zhǎng)的情況
3. 此時(shí)土居，鎖過(guò)期自動(dòng)釋放
4. 客戶端開始操作 MySQL（此時(shí)的鎖可能會(huì)被別人拿到枣购，鎖失效）

Redis 作者這里的結(jié)論就是：

• 客戶端在拿到鎖之前，無(wú)論經(jīng)歷什么耗時(shí)長(zhǎng)問(wèn)題擦耀，Redlock 都能夠在第 3 步檢測(cè)出來(lái)
• 客戶端在拿到鎖之后棉圈，發(fā)生 NPC，那 Redlock眷蜓、Zookeeper 都無(wú)能為力

所以分瘾，Redis 作者認(rèn)為 Redlock 在保證時(shí)鐘正確的基礎(chǔ)上，是可以保證正確性的吁系。

3) 質(zhì)疑 fencing token 機(jī)制

Redis 作者對(duì)于對(duì)方提出的 fencing token 機(jī)制德召，也提出了質(zhì)疑，主要分為 2 個(gè)問(wèn)題汽纤，這里最不宜理解上岗，請(qǐng)跟緊我的思路。

第一蕴坪，這個(gè)方案必須要求要操作的「共享資源服務(wù)器」有拒絕「舊 token」的能力肴掷。

例如，要操作 MySQL背传，從鎖服務(wù)拿到一個(gè)遞增數(shù)字的 token呆瞻，然后客戶端要帶著這個(gè) token 去改 MySQL 的某一行，這就需要利用 MySQL 的「事物隔離性」來(lái)做续室。

// 兩個(gè)客戶端必須利用事物和隔離性達(dá)到目的
// 注意 token 的判斷條件
UPDATE table T SET val = $new_val, current_token = $token WHERE id = $id AND current_token < $token

但如果操作的不是 MySQL 呢栋烤？例如向磁盤上寫一個(gè)文件，或發(fā)起一個(gè) HTTP 請(qǐng)求挺狰，那這個(gè)方案就無(wú)能為力了明郭，這對(duì)要操作的資源服務(wù)器买窟，提出了更高的要求。

也就是說(shuō)薯定，大部分要操作的資源服務(wù)器始绍，都是沒(méi)有這種互斥能力的。

再者话侄，既然資源服務(wù)器都有了「互斥」能力亏推，那還要分布式鎖干什么？

所以年堆，Redis 作者認(rèn)為這個(gè)方案是站不住腳的吞杭。

第二，退一步講变丧，即使 Redlock 沒(méi)有提供 fencing token 的能力芽狗，但 Redlock 已經(jīng)提供了隨機(jī)值（就是前面講的 UUID），利用這個(gè)隨機(jī)值痒蓬，也可以達(dá)到與 fencing token 同樣的效果童擎。

如何做呢？

Redis 作者只是提到了可以完成 fencing token 類似的功能攻晒，但卻沒(méi)有展開相關(guān)細(xì)節(jié)顾复，根據(jù)我查閱的資料，大概流程應(yīng)該如下鲁捏，如有錯(cuò)誤芯砸，歡迎交流~

1. 客戶端使用 Redlock 拿到鎖
2. 客戶端在操作共享資源之前，先把這個(gè)鎖的 VALUE碴萧，在要操作的共享資源上做標(biāo)記
3. 客戶端處理業(yè)務(wù)邏輯乙嘀，最后，在修改共享資源時(shí)破喻，判斷這個(gè)標(biāo)記是否與之前一樣虎谢，一樣才修改（類似 CAS 的思路）

還是以 MySQL 為例，舉個(gè)例子就是這樣的：

1. 客戶端使用 Redlock 拿到鎖
2. 客戶端要修改 MySQL 表中的某一行數(shù)據(jù)之前曹质，先把鎖的 VALUE 更新到這一行的某個(gè)字段中（這里假設(shè)為 current_token 字段)
3. 客戶端處理業(yè)務(wù)邏輯
4. 客戶端修改 MySQL 的這一行數(shù)據(jù)婴噩，把 VALUE 當(dāng)做 WHERE 條件，再修改

UPDATE table T SET val = $new_val WHERE id = $id AND current_token = $redlock_value

可見羽德，這種方案依賴 MySQL 的事物機(jī)制几莽，也達(dá)到對(duì)方提到的 fencing token 一樣的效果。

但這里還有個(gè)小問(wèn)題宅静，是網(wǎng)友參與問(wèn)題討論時(shí)提出的：兩個(gè)客戶端通過(guò)這種方案章蚣，先「標(biāo)記」再「檢查+修改」共享資源，那這兩個(gè)客戶端的操作順序無(wú)法保證耙碳小纤垂？

而用 Martin 提到的 fencing token矾策，因?yàn)檫@個(gè) token 是單調(diào)遞增的數(shù)字，資源服務(wù)器可以拒絕小的 token 請(qǐng)求峭沦，保證了操作的「順序性」贾虽！

Redis 作者對(duì)于這個(gè)問(wèn)題做了不同的解釋，我覺(jué)得很有道理吼鱼，他解釋道：分布式鎖的本質(zhì)蓬豁，是為了「互斥」，只要能保證兩個(gè)客戶端在并發(fā)時(shí)菇肃，一個(gè)成功地粪，一個(gè)失敗就好了，不需要關(guān)心「順序性」巷送。

前面 Martin 的質(zhì)疑中驶忌，一直很關(guān)心這個(gè)順序性問(wèn)題矛辕，但 Redis 的作者的看法卻不同笑跛。

綜上，Redis 作者的結(jié)論：

1聊品、作者同意對(duì)方關(guān)于「時(shí)鐘跳躍」對(duì) Redlock 的影響飞蹂，但認(rèn)為時(shí)鐘跳躍是可以避免的，取決于基礎(chǔ)設(shè)施和運(yùn)維翻屈。

2陈哑、Redlock 在設(shè)計(jì)時(shí)，充分考慮了 NPC 問(wèn)題伸眶，在 Redlock 步驟 3 之前出現(xiàn) NPC惊窖，可以保證鎖的正確性，但在步驟 3 之后發(fā)生 NPC厘贼，不止是 Redlock 有問(wèn)題界酒，其它分布式鎖服務(wù)同樣也有問(wèn)題，所以不在討論范疇內(nèi)嘴秸。

是不是覺(jué)得很有意思毁欣？

在分布式系統(tǒng)中，一個(gè)小小的鎖岳掐，居然可能會(huì)遇到這么多問(wèn)題場(chǎng)景凭疮，影響它的安全性！

不知道你看完雙方的觀點(diǎn)串述，更贊同哪一方的說(shuō)法呢执解？

別急，后面我還會(huì)綜合以上論點(diǎn)纲酗，談?wù)勛约旱睦斫狻?/p>

好衰腌，講完了雙方對(duì)于 Redis 分布鎖的爭(zhēng)論逝淹，你可能也注意到了，Martin 在他的文章中桶唐，推薦使用 Zookeeper 實(shí)現(xiàn)分布式鎖憎妙，認(rèn)為它更安全，確實(shí)如此嗎步悠？

基于 Zookeeper 的鎖安全嗎巾钉？

如果你有了解過(guò) Zookeeper，基于它實(shí)現(xiàn)的分布式鎖是這樣的：

1. 客戶端 1 和 2 都嘗試創(chuàng)建「臨時(shí)節(jié)點(diǎn)」坯约，例如 /lock
2. 假設(shè)客戶端 1 先到達(dá)熊咽，則加鎖成功，客戶端 2 加鎖失敗
3. 客戶端 1 操作共享資源
4. 客戶端 1 刪除 /lock 節(jié)點(diǎn)闹丐，釋放鎖

你應(yīng)該也看到了横殴，Zookeeper 不像 Redis 那樣，需要考慮鎖的過(guò)期時(shí)間問(wèn)題卿拴，它是采用了「臨時(shí)節(jié)點(diǎn)」衫仑，保證客戶端 1 拿到鎖后，只要連接不斷堕花，就可以一直持有鎖文狱。

而且，如果客戶端 1 異常崩潰了缘挽，那么這個(gè)臨時(shí)節(jié)點(diǎn)會(huì)自動(dòng)刪除瞄崇，保證了鎖一定會(huì)被釋放。

不錯(cuò)壕曼，沒(méi)有鎖過(guò)期的煩惱苏研，還能在異常時(shí)自動(dòng)釋放鎖，是不是覺(jué)得很完美腮郊？

其實(shí)不然摹蘑。

思考一下，客戶端 1 創(chuàng)建臨時(shí)節(jié)點(diǎn)后伴榔，Zookeeper 是如何保證讓這個(gè)客戶端一直持有鎖呢纹蝴？

原因就在于，客戶端 1 此時(shí)會(huì)與 Zookeeper 服務(wù)器維護(hù)一個(gè) Session踪少，這個(gè) Session 會(huì)依賴客戶端「定時(shí)心跳」來(lái)維持連接塘安。

如果 Zookeeper 長(zhǎng)時(shí)間收不到客戶端的心跳，就認(rèn)為這個(gè) Session 過(guò)期了援奢，也會(huì)把這個(gè)臨時(shí)節(jié)點(diǎn)刪除兼犯。

image.png

同樣地，基于此問(wèn)題，我們也討論一下 GC 問(wèn)題對(duì) Zookeeper 的鎖有何影響：

1. 客戶端 1 創(chuàng)建臨時(shí)節(jié)點(diǎn) /lock 成功切黔，拿到了鎖
2. 客戶端 1 發(fā)生長(zhǎng)時(shí)間 GC
3. 客戶端 1 無(wú)法給 Zookeeper 發(fā)送心跳砸脊，Zookeeper 把臨時(shí)節(jié)點(diǎn)「刪除」
4. 客戶端 2 創(chuàng)建臨時(shí)節(jié)點(diǎn) /lock 成功，拿到了鎖
5. 客戶端 1 GC 結(jié)束纬霞，它仍然認(rèn)為自己持有鎖（沖突）

可見凌埂，即使是使用 Zookeeper，也無(wú)法保證進(jìn)程 GC诗芜、網(wǎng)絡(luò)延遲異常場(chǎng)景下的安全性瞳抓。

這就是前面 Redis 作者在反駁的文章中提到的：如果客戶端已經(jīng)拿到了鎖，但客戶端與鎖服務(wù)器發(fā)生「失聯(lián)」（例如 GC）伏恐，那不止 Redlock 有問(wèn)題孩哑，其它鎖服務(wù)都有類似的問(wèn)題，Zookeeper 也是一樣翠桦！

所以横蜒，這里我們就能得出結(jié)論了：一個(gè)分布式鎖，在極端情況下销凑，不一定是安全的丛晌。

如果你的業(yè)務(wù)數(shù)據(jù)非常敏感，在使用分布式鎖時(shí)闻鉴，一定要注意這個(gè)問(wèn)題茵乱，不能假設(shè)分布式鎖 100% 安全。

好孟岛，現(xiàn)在我們來(lái)總結(jié)一下 Zookeeper 在使用分布式鎖時(shí)優(yōu)劣：

Zookeeper 的優(yōu)點(diǎn)：

1. 不需要考慮鎖的過(guò)期時(shí)間
2. watch 機(jī)制，加鎖失敗督勺，可以 watch 等待鎖釋放渠羞，實(shí)現(xiàn)樂(lè)觀鎖

但它的劣勢(shì)是：

1. 性能不如 Redis
2. 部署和運(yùn)維成本高
3. 客戶端與 Zookeeper 的長(zhǎng)時(shí)間失聯(lián)，鎖被釋放問(wèn)題

我對(duì)分布式鎖的理解

好了智哀，前面詳細(xì)介紹了基于 Redis 的 Redlock 和 Zookeeper 實(shí)現(xiàn)的分布鎖次询，在各種異常情況下的安全性問(wèn)題，下面我想和你聊一聊我的看法瓷叫，僅供參考屯吊，不喜勿噴。

1) 到底要不要用 Redlock摹菠？

前面也分析了盒卸，Redlock 只有建立在「時(shí)鐘正確」的前提下，才能正常工作次氨，如果你可以保證這個(gè)前提蔽介，那么可以拿來(lái)使用。

但保證時(shí)鐘正確，我認(rèn)為并不是你想的那么簡(jiǎn)單就能做到的虹蓄。

第一犀呼，從硬件角度來(lái)說(shuō)，時(shí)鐘發(fā)生偏移是時(shí)有發(fā)生薇组，無(wú)法避免的外臂。

例如，CPU 溫度律胀、機(jī)器負(fù)載专钉、芯片材料都是有可能導(dǎo)致時(shí)鐘發(fā)生偏移。

第二累铅，從我的工作經(jīng)歷來(lái)說(shuō)跃须，曾經(jīng)就遇到過(guò)時(shí)鐘錯(cuò)誤、運(yùn)維暴力修改時(shí)鐘的情況發(fā)生娃兽，進(jìn)而影響了系統(tǒng)的正確性菇民，所以，人為錯(cuò)誤也是很難完全避免的投储。

所以第练，我對(duì) Redlock 的個(gè)人看法是，盡量不用它玛荞，而且它的性能不如單機(jī)版 Redis娇掏，部署成本也高，我還是會(huì)優(yōu)先考慮使用 Redis「主從+哨兵」的模式勋眯，實(shí)現(xiàn)分布式鎖婴梧。

那正確性如何保證呢？第二點(diǎn)給你答案客蹋。

2) 如何正確使用分布式鎖塞蹭？

在分析 Martin 觀點(diǎn)時(shí)，它提到了 fencing token 的方案讶坯，給我了很大的啟發(fā)番电，雖然這種方案有很大的局限性，但對(duì)于保證「正確性」的場(chǎng)景辆琅，是一個(gè)非常好的思路漱办。

所以，我們可以把這兩者結(jié)合起來(lái)用：

1婉烟、使用分布式鎖娩井，在上層完成「互斥」目的，雖然極端情況下鎖會(huì)失效隅很，但它可以最大程度把并發(fā)請(qǐng)求阻擋在最上層撞牢，減輕操作資源層的壓力率碾。

2、但對(duì)于要求數(shù)據(jù)絕對(duì)正確的業(yè)務(wù)屋彪，在資源層一定要做好「兜底」所宰，設(shè)計(jì)思路可以借鑒 fencing token 的方案來(lái)做。

兩種思路結(jié)合畜挥，我認(rèn)為對(duì)于大多數(shù)業(yè)務(wù)場(chǎng)景仔粥，已經(jīng)可以滿足要求了。

總結(jié)

好了蟹但，總結(jié)一下躯泰。

我們主要探討了基于 Redis 實(shí)現(xiàn)的分布式鎖，究竟是否安全這個(gè)問(wèn)題华糖。

從最簡(jiǎn)單分布式鎖的實(shí)現(xiàn)麦向，到處理各種異常場(chǎng)景，再到引出 Redlock客叉，以及兩個(gè)分布式專家的辯論诵竭，得出了 Redlock 的適用場(chǎng)景。

最后兼搏，我們還對(duì)比了 Zookeeper 在做分布式鎖時(shí)卵慰，可能會(huì)遇到的問(wèn)題，以及與 Redis 的差異佛呻。

這里我把這些內(nèi)容總結(jié)成了思維導(dǎo)圖裳朋，方便你理解。

image.png

后記

這些內(nèi)容的信息量其實(shí)是非常大的吓著，我覺(jué)得應(yīng)該把分布鎖的問(wèn)題鲤嫡，徹底講清楚了。

如果你沒(méi)有理解夜矗，我建議你多讀幾遍泛范，并在腦海中構(gòu)建各種假定的場(chǎng)景，反復(fù)思辨紊撕。

在寫這些內(nèi)容時(shí)，我又重新研讀了兩位大神關(guān)于 Redlock 爭(zhēng)辯的這兩篇文章赡突，可謂是是收獲滿滿对扶，在這里也分享一些心得給你。

1惭缰、在分布式系統(tǒng)環(huán)境下浪南，看似完美的設(shè)計(jì)方案，可能并不是那么「嚴(yán)絲合縫」漱受，如果稍加推敲络凿，就會(huì)發(fā)現(xiàn)各種問(wèn)題。所以，在思考分布式系統(tǒng)問(wèn)題時(shí)絮记，一定要謹(jǐn)慎再謹(jǐn)慎摔踱。

2、從 Redlock 的爭(zhēng)辯中怨愤，我們不要過(guò)多關(guān)注對(duì)錯(cuò)派敷，而是要多學(xué)習(xí)大神的思考方式，以及對(duì)一個(gè)問(wèn)題嚴(yán)格審查的嚴(yán)謹(jǐn)精神撰洗。

最后篮愉，用 Martin 在對(duì)于 Redlock 爭(zhēng)論過(guò)后，寫下的感悟來(lái)結(jié)尾：

“前人已經(jīng)為我們創(chuàng)造出了許多偉大的成果：站在巨人的肩膀上差导，我們可以才得以構(gòu)建更好的軟件试躏。無(wú)論如何，通過(guò)爭(zhēng)論和檢查它們是否經(jīng)得起別人的詳細(xì)審查设褐，這是學(xué)習(xí)過(guò)程的一部分颠蕴。但目標(biāo)應(yīng)該是獲取知識(shí)，而不是為了說(shuō)服別人络断，讓別人相信你是對(duì)的裁替。有時(shí)候，那只是意味著停下來(lái)貌笨，好好地想一想弱判。”

共勉。