這篇文章我想和你聊一聊，關(guān)于 Redis 分布式鎖的「安全性」問題孤里。

Redis 分布式鎖的話題伏伯，很多文章已經(jīng)寫爛了，我為什么還要寫這篇文章呢捌袜？

因為我發(fā)現(xiàn)網(wǎng)上 99% 的文章说搅，并沒有把這個問題真正講清楚。導致很多讀者看了很多文章虏等，依舊云里霧里弄唧。例如下面這些問題，你能清晰地回答上來嗎霍衫？

• 基于 Redis 如何實現(xiàn)一個分布式鎖候引？
• Redis 分布式鎖真的安全嗎？
• Redis 的 Redlock 有什么問題敦跌？一定安全嗎澄干？
• 業(yè)界爭論 Redlock，到底在爭論什么峰髓？哪種觀點是對的傻寂？
• 分布式鎖到底用 Redis 還是 Zookeeper？
• 實現(xiàn)一個有「容錯性」的分布式鎖携兵，都需要考慮哪些問題？

這篇文章搂誉，我就來把這些問題徹底講清楚徐紧。

讀完這篇文章，你不僅可以徹底了解分布式鎖炭懊，還會對「分布式系統(tǒng)」有更加深刻的理解并级。

文章有點長，但干貨很多侮腹，希望你可以耐心讀完嘲碧。

為什么需要分布式鎖？

在開始講分布式鎖之前父阻，有必要簡單介紹一下愈涩，為什么需要分布式鎖？

與分布式鎖相對應的是「單機鎖」加矛，我們在寫多線程程序時履婉，避免同時操作一個共享變量產(chǎn)生數(shù)據(jù)問題，通常會使用一把鎖來「互斥」斟览，以保證共享變量的正確性毁腿，其使用范圍是在「同一個進程」中。

如果換做是多個進程，需要同時操作一個共享資源已烤，如何互斥呢鸠窗？

例如，現(xiàn)在的業(yè)務(wù)應用通常都是微服務(wù)架構(gòu)胯究，這也意味著一個應用會部署多個進程稍计，那這多個進程如果需要修改 MySQL 中的同一行記錄時，為了避免操作亂序?qū)е聰?shù)據(jù)錯誤唐片，此時丙猬，我們就需要引入「分布式鎖」來解決這個問題了。

想要實現(xiàn)分布式鎖费韭，必須借助一個外部系統(tǒng)茧球，所有進程都去這個系統(tǒng)上申請「加鎖」。

而這個外部系統(tǒng)星持，必須要實現(xiàn)「互斥」的能力抢埋，即兩個請求同時進來，只會給一個進程返回成功督暂，另一個返回失斁韭ⅰ（或等待）。

這個外部系統(tǒng)逻翁，可以是 MySQL饥努，也可以是 Redis 或 Zookeeper。但為了追求更好的性能八回，我們通常會選擇使用 Redis 或 Zookeeper 來做酷愧。

下面我就以 Redis 為主線，由淺入深缠诅，帶你深度剖析一下溶浴，分布式鎖的各種「安全性」問題，幫你徹底理解分布式鎖管引。

分布式鎖怎么實現(xiàn)士败？

我們從最簡單的開始講起。

想要實現(xiàn)分布式鎖褥伴，必須要求 Redis 有「互斥」的能力谅将，我們可以使用 SETNX 命令，這個命令表示SET if Not eXists噩翠，即如果 key 不存在戏自，才會設(shè)置它的值，否則什么也不做伤锚。

兩個客戶端進程可以執(zhí)行這個命令擅笔，達到互斥志衣，就可以實現(xiàn)一個分布式鎖。

客戶端 1 申請加鎖猛们，加鎖成功：

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

客戶端 2 申請加鎖，因為后到達弯淘，加鎖失斅痰辍：

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

此時庐橙，加鎖成功的客戶端假勿，就可以去操作「共享資源」，例如态鳖，修改 MySQL 的某一行數(shù)據(jù)转培，或者調(diào)用一個 API 請求。

操作完成后浆竭，還要及時釋放鎖浸须，給后來者讓出操作共享資源的機會。如何釋放鎖呢邦泄？

也很簡單删窒，直接使用 DEL 命令刪除這個 key 即可：

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

這個邏輯非常簡單，整體的路程就是這樣：

但是顺囊，它存在一個很大的問題肌索，當客戶端 1 拿到鎖后，如果發(fā)生下面的場景特碳，就會造成「死鎖」：

1. 程序處理業(yè)務(wù)邏輯異常驶社，沒及時釋放鎖
2. 進程掛了，沒機會釋放鎖

這時测萎，這個客戶端就會一直占用這個鎖，而其它客戶端就「永遠」拿不到這把鎖了届巩。

怎么解決這個問題呢硅瞧？

如何避免死鎖？

我們很容易想到的方案是恕汇，在申請鎖時腕唧，給這把鎖設(shè)置一個「租期」。

在 Redis 中實現(xiàn)時瘾英，就是給這個 key 設(shè)置一個「過期時間」枣接。這里我們假設(shè)，操作共享資源的時間不會超過 10s缺谴，那么在加鎖時但惶，給這個 key 設(shè)置 10s 過期即可：

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

這樣一來，無論客戶端是否異常，這個鎖都可以在 10s 后被「自動釋放」膀曾，其它客戶端依舊可以拿到鎖县爬。

但這樣真的沒問題嗎？

還是有問題添谊。

現(xiàn)在的操作财喳，加鎖、設(shè)置過期是 2 條命令斩狱，有沒有可能只執(zhí)行了第一條耳高，第二條卻「來不及」執(zhí)行的情況發(fā)生呢？例如：

1. SETNX 執(zhí)行成功所踊，執(zhí)行 EXPIRE 時由于網(wǎng)絡(luò)問題泌枪，執(zhí)行失敗
2. SETNX 執(zhí)行成功，Redis 異常宕機污筷，EXPIRE 沒有機會執(zhí)行
3. SETNX 執(zhí)行成功工闺，客戶端異常崩潰，EXPIRE 也沒有機會執(zhí)行

總之瓣蛀，這兩條命令不能保證是原子操作（一起成功）陆蟆，就有潛在的風險導致過期時間設(shè)置失敗，依舊發(fā)生「死鎖」問題惋增。

怎么辦叠殷？

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

但在 Redis 2.6.12 之后稽亏，Redis 擴展了 SET 命令的參數(shù)壶冒，用這一條命令就可以了：

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

這樣就解決了死鎖問題，也比較簡單截歉。

我們再來看分析下胖腾，它還有什么問題？

試想這樣一種場景：

1. 客戶端 1 加鎖成功瘪松，開始操作共享資源
2. 客戶端 1 操作共享資源的時間咸作，「超過」了鎖的過期時間，鎖被「自動釋放」
3. 客戶端 2 加鎖成功宵睦，開始操作共享資源
4. 客戶端 1 操作共享資源完成记罚，釋放鎖（但釋放的是客戶端 2 的鎖）

看到了么，這里存在兩個嚴重的問題：

1. 鎖過期：客戶端 1 操作共享資源耗時太久壳嚎，導致鎖被自動釋放桐智，之后被客戶端 2 持有
2. 釋放別人的鎖：客戶端 1 操作共享資源完成后末早，卻又釋放了客戶端 2 的鎖

導致這兩個問題的原因是什么？我們一個個來看酵使。

第一個問題荐吉，可能是我們評估操作共享資源的時間不準確導致的。

例如口渔，操作共享資源的時間「最慢」可能需要 15s样屠，而我們卻只設(shè)置了 10s 過期，那這就存在鎖提前過期的風險缺脉。

過期時間太短痪欲，那增大冗余時間，例如設(shè)置過期時間為 20s攻礼，這樣總可以了吧业踢？

這樣確實可以「緩解」這個問題，降低出問題的概率礁扮，但依舊無法「徹底解決」問題知举。

為什么？

原因在于太伊，客戶端在拿到鎖之后雇锡，在操作共享資源時，遇到的場景有可能是很復雜的僚焦，例如锰提，程序內(nèi)部發(fā)生異常、網(wǎng)絡(luò)請求超時等等芳悲。

既然是「預估」時間立肘，也只能是大致計算，除非你能預料并覆蓋到所有導致耗時變長的場景名扛，但這其實很難谅年。

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

別急肮韧，關(guān)于這個問題踢故，我會在后面詳細來講對應的解決方案。

我們繼續(xù)來看第二個問題惹苗。

第二個問題在于，一個客戶端釋放了其它客戶端持有的鎖耸峭。

想一下桩蓉，導致這個問題的關(guān)鍵點在哪？

重點在于劳闹，每個客戶端在釋放鎖時院究，都是「無腦」操作洽瞬，并沒有檢查這把鎖是否還「歸自己持有」，所以就會發(fā)生釋放別人鎖的風險业汰，這樣的解鎖流程伙窃，很不「嚴謹」！

如何解決這個問題呢样漆？

鎖被別人釋放怎么辦?

解決辦法是：客戶端在加鎖時为障，設(shè)置一個只有自己知道的「唯一標識」進去。

例如放祟，可以是自己的線程 ID鳍怨，也可以是一個 UUID（隨機且唯一），這里我們以 UUID 舉例：

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

這里假設(shè) 20s 操作共享時間完全足夠跪妥，先不考慮鎖自動過期的問題鞋喇。

之后，在釋放鎖時眉撵，要先判斷這把鎖是否還歸自己持有侦香，偽代碼可以這么寫：

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

這里釋放鎖使用的是 GET + DEL 兩條命令纽疟，這時罐韩，又會遇到我們前面講的原子性問題了。

1. 客戶端 1 執(zhí)行 GET仰挣，判斷鎖是自己的
2. 客戶端 2 執(zhí)行了 SET 命令伴逸，強制獲取到鎖（雖然發(fā)生概率比較低，但我們需要嚴謹?shù)乜紤]鎖的安全性模型）
3. 客戶端 1 執(zhí)行 DEL膘壶，卻釋放了客戶端 2 的鎖

由此可見错蝴，這兩個命令還是必須要原子執(zhí)行才行。

怎樣原子執(zhí)行呢颓芭？Lua 腳本顷锰。

我們可以把這個邏輯，寫成 Lua 腳本亡问，讓 Redis 來執(zhí)行官紫。

因為 Redis 處理每一個請求是「單線程」執(zhí)行的，在執(zhí)行一個 Lua 腳本時州藕，其它請求必須等待束世，直到這個 Lua 腳本處理完成，這樣一來床玻，GET + DEL 之間就不會插入其它命令了毁涉。

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

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

好了锈死，這樣一路優(yōu)化贫堰，整個的加鎖穆壕、解鎖的流程就更「嚴謹」了。

這里我們先小結(jié)一下其屏，基于 Redis 實現(xiàn)的分布式鎖喇勋，一個嚴謹?shù)牡牧鞒倘缦拢?/p>

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

好川背，有了這個完整的鎖模型，讓我們重新回到前面提到的第一個問題睦优。

鎖過期時間不好評估怎么辦渗常？

鎖過期時間不好評估怎么辦？

前面我們提到汗盘，鎖的過期時間如果評估不好皱碘，這個鎖就會有「提前」過期的風險。

當時給的妥協(xié)方案是隐孽，盡量「冗余」過期時間癌椿，降低鎖提前過期的概率。

這個方案其實也不能完美解決問題菱阵，那怎么辦呢踢俄？

是否可以設(shè)計這樣的方案：加鎖時，先設(shè)置一個過期時間晴及，然后我們開啟一個「守護線程」都办，定時去檢測這個鎖的失效時間，如果鎖快要過期了虑稼，操作共享資源還未完成琳钉，那么就自動對鎖進行「續(xù)期」，重新設(shè)置過期時間蛛倦。

這確實一種比較好的方案歌懒。

如果你是 Java 技術(shù)棧，幸運的是溯壶，已經(jīng)有一個庫把這些工作都封裝好了：Redisson及皂。

Redisson 是一個 Java 語言實現(xiàn)的 Redis SDK 客戶端，在使用分布式鎖時且改，它就采用了「自動續(xù)期」的方案來避免鎖過期验烧，這個守護線程我們一般也把它叫做「看門狗」線程。

除此之外又跛，這個 SDK 還封裝了很多易用的功能：

• 可重入鎖
• 樂觀鎖
• 公平鎖
• 讀寫鎖
• Redlock（紅鎖噪窘，下面會詳細講）

這個 SDK 提供的 API 非常友好，它可以像操作本地鎖的方式，操作分布式鎖倔监。如果你是 Java 技術(shù)棧，可以直接把它用起來菌仁。

這里不重點介紹 Redisson 的使用浩习，大家可以看官方 Github 學習如何使用，比較簡單济丘。

到這里我們再小結(jié)一下谱秽，基于 Redis 的實現(xiàn)分布式鎖，前面遇到的問題摹迷，以及對應的解決方案：

• 死鎖：設(shè)置過期時間
• 過期時間評估不好疟赊，鎖提前過期：守護線程，自動續(xù)期
• 鎖被別人釋放：鎖寫入唯一標識峡碉，釋放鎖先檢查標識近哟，再釋放

還有哪些問題場景，會危害 Redis 鎖的安全性呢鲫寄？

之前分析的場景都是吉执，鎖在「單個」Redis 實例中可能產(chǎn)生的問題，并沒有涉及到 Redis 的部署架構(gòu)細節(jié)地来。

而我們在使用 Redis 時戳玫，一般會采用主從集群 + 哨兵的模式部署，這樣做的好處在于未斑，當主庫異常宕機時咕宿，哨兵可以實現(xiàn)「故障自動切換」，把從庫提升為主庫蜡秽，繼續(xù)提供服務(wù)府阀，以此保證可用性。

那當「主從發(fā)生切換」時载城，這個分布鎖會依舊安全嗎肌似？

試想這樣的場景：

1. 客戶端 1 在主庫上執(zhí)行 SET 命令，加鎖成功
2. 此時诉瓦，主庫異常宕機川队，SET 命令還未同步到從庫上（主從復制是異步的）
3. 從庫被哨兵提升為新主庫，這個鎖在新的主庫上睬澡，丟失了固额！

可見，當引入 Redis 副本后煞聪，分布鎖還是可能會受到影響斗躏。

怎么解決這個問題？

為此昔脯，Redis 的作者提出一種解決方案啄糙，就是我們經(jīng)常聽到的 Redlock（紅鎖）近迁。

它真的可以解決上面這個問題嗎？

Redlock 真的安全嗎个初？

好助币，終于到了這篇文章的重頭戲。把嘌恪诞丽？上面講的那么多問題，難道只是基礎(chǔ)拐格？

是的僧免，那些只是開胃菜，真正的硬菜捏浊，從這里剛剛開始懂衩。

如果上面講的內(nèi)容，你還沒有理解呛伴，我建議你重新閱讀一遍勃痴，先理清整個加鎖、解鎖的基本流程热康。

如果你已經(jīng)對 Redlock 有所了解沛申，這里可以跟著我再復習一遍，如果你不了解 Redlock姐军，沒關(guān)系铁材，我會帶你重新認識它。

值得提醒你的是奕锌，后面我不僅僅是講 Redlock 的原理著觉，還會引出有關(guān)「分布式系統(tǒng)」中的很多問題，你最好跟緊我的思路惊暴，在腦中一起分析問題的答案饼丘。

現(xiàn)在我們來看，Redis 作者提出的 Redlock 方案辽话，是如何解決主從切換后肄鸽，鎖失效問題的。

Redlock 的方案基于 2 個前提：

1. 不再需要部署從庫和哨兵實例油啤，只部署主庫
2. 但主庫要部署多個典徘，官方推薦至少 5 個實例

也就是說，想用使用 Redlock益咬，你至少要部署 5 個 Redis 實例逮诲，而且都是主庫，它們之間沒有任何關(guān)系，都是一個個孤立的實例梅鹦。

注意：不是部署 Redis Cluster裆甩，就是部署 5 個簡單的 Redis 實例。

Redlock 具體如何使用呢齐唆？

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

1. 客戶端先獲取「當前時間戳T1」
2. 客戶端依次向這 5 個 Redis 實例發(fā)起加鎖請求（用前面講到的 SET 命令），且每個請求會設(shè)置超時時間（毫秒級蝶念，要遠小于鎖的有效時間），如果某一個實例加鎖失斢蟪瘛（包括網(wǎng)絡(luò)超時媒殉、鎖被其它人持有等各種異常情況），就立即向下一個 Redis 實例申請加鎖
3. 如果客戶端從 >=3 個（大多數(shù)）以上 Redis 實例加鎖成功摔敛，則再次獲取「當前時間戳T2」廷蓉，如果 T2 - T1 < 鎖的過期時間，此時马昙，認為客戶端加鎖成功桃犬，否則認為加鎖失敗
4. 加鎖成功，去操作共享資源（例如修改 MySQL 某一行行楞，或發(fā)起一個 API 請求）
5. 加鎖失敗攒暇，向「全部節(jié)點」發(fā)起釋放鎖請求（前面講到的 Lua 腳本釋放鎖）

我簡單幫你總結(jié)一下，有 4 個重點：

1. 客戶端在多個 Redis 實例上申請加鎖
2. 必須保證大多數(shù)節(jié)點加鎖成功
3. 大多數(shù)節(jié)點加鎖的總耗時子房，要小于鎖設(shè)置的過期時間
4. 釋放鎖形用，要向全部節(jié)點發(fā)起釋放鎖請求

第一次看可能不太容易理解，建議你把上面的文字多看幾遍证杭，加深記憶田度。

然后，記住這 5 步解愤，非常重要镇饺，下面會根據(jù)這個流程，剖析各種可能導致鎖失效的問題假設(shè)送讲。

好奸笤，明白了 Redlock 的流程，我們來看 Redlock 為什么要這么做李茫。

1) 為什么要在多個實例上加鎖揭保？

本質(zhì)上是為了「容錯」，部分實例異常宕機魄宏，剩余的實例加鎖成功秸侣，整個鎖服務(wù)依舊可用。

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

多個 Redis 實例一起來用椭坚，其實就組成了一個「分布式系統(tǒng)」。

在分布式系統(tǒng)中搏色，總會出現(xiàn)「異常節(jié)點」善茎，所以，在談?wù)摲植际较到y(tǒng)問題時频轿，需要考慮異常節(jié)點達到多少個垂涯，也依舊不會影響整個系統(tǒng)的「正確性」。

這是一個分布式系統(tǒng)「容錯」問題航邢，這個問題的結(jié)論是：如果只存在「故障」節(jié)點耕赘，只要大多數(shù)節(jié)點正常，那么整個系統(tǒng)依舊是可以提供正確服務(wù)的膳殷。

這個問題的模型操骡，就是我們經(jīng)常聽到的「拜占庭將軍」問題，感興趣可以去看算法的推演過程赚窃。

3) 為什么步驟 3 加鎖成功后册招，還要計算加鎖的累計耗時？

因為操作的是多個節(jié)點勒极，所以耗時肯定會比操作單個實例耗時更久是掰，而且，因為是網(wǎng)絡(luò)請求河质，網(wǎng)絡(luò)情況是復雜的冀惭，有可能存在延遲、丟包掀鹅、超時等情況發(fā)生散休，網(wǎng)絡(luò)請求越多，異常發(fā)生的概率就越大乐尊。

所以戚丸，即使大多數(shù)節(jié)點加鎖成功，但如果加鎖的累計耗時已經(jīng)「超過」了鎖的過期時間扔嵌，那此時有些實例上的鎖可能已經(jīng)失效了限府，這個鎖就沒有意義了。

4) 為什么釋放鎖痢缎，要操作所有節(jié)點胁勺？

在某一個 Redis 節(jié)點加鎖時，可能因為「網(wǎng)絡(luò)原因」導致加鎖失敗独旷。

例如署穗，客戶端在一個 Redis 實例上加鎖成功寥裂，但在讀取響應結(jié)果時，網(wǎng)絡(luò)問題導致讀取失敗案疲，那這把鎖其實已經(jīng)在 Redis 上加鎖成功了封恰。

所以，釋放鎖時褐啡，不管之前有沒有加鎖成功诺舔，需要釋放「所有節(jié)點」的鎖，以保證清理節(jié)點上「殘留」的鎖备畦。

好了低飒，明白了 Redlock 的流程和相關(guān)問題，看似 Redlock 確實解決了 Redis 節(jié)點異常宕機鎖失效的問題懂盐，保證了鎖的「安全性」逸嘀。

但事實真的如此嗎？

Redlock 的爭論誰對誰錯允粤？

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

這個專家叫 Martin类垫，是英國劍橋大學的一名分布式系統(tǒng)研究員。在此之前他曾是軟件工程師和企業(yè)家琅坡，從事大規(guī)模數(shù)據(jù)基礎(chǔ)設(shè)施相關(guān)的工作悉患。它還經(jīng)常在大會做演講，寫博客榆俺，寫書售躁，也是開源貢獻者。

他馬上寫了篇文章茴晋，質(zhì)疑這個 Redlock 的算法模型是有問題的陪捷，并對分布式鎖的設(shè)計，提出了自己的看法诺擅。

之后市袖，Redis 作者 Antirez 面對質(zhì)疑，不甘示弱烁涌，也寫了一篇文章苍碟，反駁了對方的觀點，并詳細剖析了 Redlock 算法模型的更多設(shè)計細節(jié)撮执。

而且微峰，關(guān)于這個問題的爭論，在當時互聯(lián)網(wǎng)上也引起了非常激烈的討論抒钱。

二人思路清晰蜓肆，論據(jù)充分颜凯，這是一場高手過招，也是分布式系統(tǒng)領(lǐng)域非常好的一次思想的碰撞症杏！雙方都是分布式系統(tǒng)領(lǐng)域的專家装获，卻對同一個問題提出很多相反的論斷，究竟是怎么回事厉颤？

下面我會從他們的爭論文章中穴豫，提取重要的觀點，整理呈現(xiàn)給你逼友。

提醒：后面的信息量極大精肃，可能不宜理解，最好放慢速度閱讀帜乞。

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

在他的文章中司抱，主要闡述了 4 個論點：

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

Martin 表示黎烈，你必須先清楚你在使用分布式鎖的目的是什么习柠？

他認為有兩個目的。

第一照棋，效率资溃。

使用分布式鎖的互斥能力，是避免不必要地做同樣的兩次工作（例如一些昂貴的計算任務(wù)）烈炭。如果鎖失效溶锭，并不會帶來「惡性」的后果，例如發(fā)了 2 次郵件等符隙，無傷大雅趴捅。

第二，正確性霹疫。

使用鎖用來防止并發(fā)進程互相干擾拱绑。如果鎖失效，會造成多個進程同時操作同一條數(shù)據(jù)丽蝎，產(chǎn)生的后果是數(shù)據(jù)嚴重錯誤欺栗、永久性不一致、數(shù)據(jù)丟失等惡性問題征峦，就像給患者服用重復劑量的藥物一樣迟几，后果嚴重。

他認為栏笆，如果你是為了前者——效率类腮，那么使用單機版 Redis 就可以了，即使偶爾發(fā)生鎖失效（宕機蛉加、主從切換）蚜枢，都不會產(chǎn)生嚴重的后果缸逃。而使用 Redlock 太重了，沒必要厂抽。

而如果是為了正確性需频，Martin 認為 Redlock 根本達不到安全性的要求，也依舊存在鎖失效的問題筷凤！

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

Martin 表示昭殉，一個分布式系統(tǒng)，更像一個復雜的「野獸」藐守，存在著你想不到的各種異常情況挪丢。

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

• N：Network Delay乾蓬，網(wǎng)絡(luò)延遲
• P：Process Pause，進程暫停（GC）
• C：Clock Drift慎恒，時鐘漂移

Martin 用一個進程暫停（GC）的例子任内，指出了 Redlock 安全性問題：

1. 客戶端 1 請求鎖定節(jié)點 A、B融柬、C族奢、D、E
2. 客戶端 1 的拿到鎖后丹鸿，進入 GC（時間比較久）
3. 所有 Redis 節(jié)點上的鎖都過期了
4. 客戶端 2 獲取到了 A、B棚品、C靠欢、D、E 上的鎖
5. 客戶端 1 GC 結(jié)束铜跑，認為成功獲取鎖
6. 客戶端 2 也認為獲取到了鎖门怪，發(fā)生「沖突」

Martin 認為，GC 可能發(fā)生在程序的任意時刻锅纺，而且執(zhí)行時間是不可控的掷空。

注：當然，即使是使用沒有 GC 的編程語言囤锉，在發(fā)生網(wǎng)絡(luò)延遲坦弟、時鐘漂移時，也都有可能導致 Redlock 出現(xiàn)問題官地，這里 Martin 只是拿 GC 舉例酿傍。

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

又或者，當多個 Redis 節(jié)點「時鐘」發(fā)生問題時驱入，也會導致 Redlock 鎖失效赤炒。

1. 客戶端 1 獲取節(jié)點 A氯析、B、C 上的鎖莺褒，但由于網(wǎng)絡(luò)問題掩缓，無法訪問 D 和 E
2. 節(jié)點 C 上的時鐘「向前跳躍」，導致鎖到期
3. 客戶端 2 獲取節(jié)點 C遵岩、D你辣、E 上的鎖，由于網(wǎng)絡(luò)問題旷余，無法訪問 A 和 B
4. 客戶端 1 和 2 現(xiàn)在都相信它們持有了鎖（沖突）

Martin 覺得绢记，Redlock 必須「強依賴」多個節(jié)點的時鐘是保持同步的，一旦有節(jié)點時鐘發(fā)生錯誤正卧，那這個算法模型就失效了蠢熄。

即使 C 不是時鐘跳躍，而是「崩潰后立即重啟」炉旷，也會發(fā)生類似的問題签孔。

Martin 繼續(xù)闡述，機器的時鐘發(fā)生錯誤窘行，是很有可能發(fā)生的：

• 系統(tǒng)管理員「手動修改」了機器時鐘
• 機器時鐘在同步 NTP 時間時饥追，發(fā)生了大的「跳躍」

總之，Martin 認為罐盔，Redlock 的算法是建立在「同步模型」基礎(chǔ)上的但绕，有大量資料研究表明，同步模型的假設(shè)惶看，在分布式系統(tǒng)中是有問題的捏顺。

在混亂的分布式系統(tǒng)的中，你不能假設(shè)系統(tǒng)時鐘就是對的纬黎，所以幅骄，你必須非常小心你的假設(shè)。

4) 提出 fecing token 的方案本今，保證正確性

相對應的拆座，Martin 提出一種被叫作 fecing token 的方案，保證分布式鎖的正確性冠息。

這個模型流程如下：

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

這樣一來，無論 NPC 哪種異常情況發(fā)生逛艰，都可以保證分布式鎖的安全性岖赋，因為它是建立在「異步模型」上的。

而 Redlock 無法提供類似 fecing token 的方案瓮孙，所以它無法保證安全性唐断。

他還表示选脊，一個好的分布式鎖，無論 NPC 怎么發(fā)生脸甘，可以不在規(guī)定時間內(nèi)給出結(jié)果恳啥，但并不會給出一個錯誤的結(jié)果。也就是只會影響到鎖的「性能」（或稱之為活性）丹诀，而不會影響它的「正確性」钝的。

Martin 的結(jié)論：

1、Redlock 不倫不類：它對于效率來講铆遭，Redlock 比較重硝桩，沒必要這么做，而對于正確性來說枚荣，Redlock 是不夠安全的碗脊。

2、時鐘假設(shè)不合理：該算法對系統(tǒng)時鐘做出了危險的假設(shè)（假設(shè)多個節(jié)點機器時鐘都是一致的）橄妆，如果不滿足這些假設(shè)衙伶，鎖就會失效。

3害碾、無法保證正確性：Redlock 不能提供類似 fencing token 的方案矢劲，所以解決不了正確性的問題。為了正確性慌随，請使用有「共識系統(tǒng)」的軟件芬沉，例如 Zookeeper。

好了阁猜，以上就是 Martin 反對使用 Redlock 的觀點丸逸，看起來有理有據(jù)。

下面我們來看 Redis 作者 Antirez 是如何反駁的蹦漠。

Redis 作者 Antirez 的反駁

在 Redis 作者的文章中，重點有 3 個：

1) 解釋時鐘問題

首先车海，Redis 作者一眼就看穿了對方提出的最為核心的問題：時鐘問題笛园。

Redis 作者表示，Redlock 并不需要完全一致的時鐘侍芝，只需要大體一致就可以了研铆，允許有「誤差」。

例如要計時 5s州叠，但實際可能記了 4.5s棵红，之后又記了 5.5s，有一定誤差咧栗，但只要不超過「誤差范圍」鎖失效時間即可逆甜，這種對于時鐘的精度的要求并不是很高虱肄，而且這也符合現(xiàn)實環(huán)境。

對于對方提到的「時鐘修改」問題交煞，Redis 作者反駁到：

1. 手動修改時鐘：不要這么做就好了咏窿，否則你直接修改 Raft 日志，那 Raft 也會無法工作...
2. 時鐘跳躍：通過「恰當?shù)倪\維」素征，保證機器時鐘不會大幅度跳躍（每次通過微小的調(diào)整來完成）集嵌，實際上這是可以做到的

為什么 Redis 作者優(yōu)先解釋時鐘問題？因為在后面的反駁過程中御毅，需要依賴這個基礎(chǔ)做進一步解釋根欧。

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

之后端蛆，Redis 作者對于對方提出的凤粗，網(wǎng)絡(luò)延遲wan、進程 GC 可能導致 Redlock 失效的問題欺税，也做了反駁：

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

1. 客戶端 1 請求鎖定節(jié)點 A、B晚凿、C亭罪、D、E
2. 客戶端 1 的拿到鎖后歼秽，進入 GC
3. 所有 Redis 節(jié)點上的鎖都過期了
4. 客戶端 2 獲取節(jié)點 A应役、B、C燥筷、D箩祥、E 上的鎖
5. 客戶端 1 GC 結(jié)束，認為成功獲取鎖
6. 客戶端 2 也認為獲取到鎖肆氓，發(fā)生「沖突」

Redis 作者反駁到袍祖，這個假設(shè)其實是有問題的，Redlock 是可以保證鎖安全的谢揪。

這是怎么回事呢蕉陋？

還記得前面介紹 Redlock 流程的那 5 步嗎？這里我再拿過來讓你復習一下拨扶。

1. 客戶端先獲取「當前時間戳T1」
2. 客戶端依次向這 5 個 Redis 實例發(fā)起加鎖請求（用前面講到的 SET 命令）凳鬓，且每個請求會設(shè)置超時時間（毫秒級，要遠小于鎖的有效時間）患民，如果某一個實例加鎖失斔蹙佟（包括網(wǎng)絡(luò)超時、鎖被其它人持有等各種異常情況），就立即向下一個 Redis 實例申請加鎖
3. 如果客戶端從 3 個（大多數(shù)）以上 Redis 實例加鎖成功仅孩，則再次獲取「當前時間戳T2」托猩，如果 T2 - T1 < 鎖的過期時間，此時杠氢，認為客戶端加鎖成功站刑，否則認為加鎖失敗
4. 加鎖成功，去操作共享資源（例如修改 MySQL 某一行鼻百，或發(fā)起一個 API 請求）
5. 加鎖失敗绞旅，向「全部節(jié)點」發(fā)起釋放鎖請求（前面講到的 Lua 腳本釋放鎖）

注意，重點是 1-3温艇，在步驟 3因悲，加鎖成功后為什么要重新獲取「當前時間戳T2」？還用 T2 - T1 的時間勺爱，與鎖的過期時間做比較晃琳？

Redis 作者強調(diào)：如果在 1-3 發(fā)生了網(wǎng)絡(luò)延遲、進程 GC 等耗時長的異常情況琐鲁，那在第 3 步 T2 - T1卫旱，是可以檢測出來的，如果超出了鎖設(shè)置的過期時間围段，那這時就認為加鎖會失敗顾翼，之后釋放所有節(jié)點的鎖就好了！

Redis 作者繼續(xù)論述奈泪，如果對方認為适贸，發(fā)生網(wǎng)絡(luò)延遲、進程 GC 是在步驟 3 之后涝桅，也就是客戶端確認拿到了鎖拜姿，去操作共享資源的途中發(fā)生了問題，導致鎖失效冯遂，那這不止是 Redlock 的問題蕊肥，任何其它鎖服務(wù)例如 Zookeeper，都有類似的問題蛤肌，這不在討論范疇內(nèi)壁却。

這里我舉個例子解釋一下這個問題：

1. 客戶端通過 Redlock 成功獲取到鎖（通過了大多數(shù)節(jié)點加鎖成功、加鎖耗時檢查邏輯）
2. 客戶端開始操作共享資源寻定，此時發(fā)生網(wǎng)絡(luò)延遲儒洛、進程 GC 等耗時很長的情況
3. 此時精耐，鎖過期自動釋放
4. 客戶端開始操作 MySQL（此時的鎖可能會被別人拿到狼速，鎖失效）

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

• 客戶端在拿到鎖之前，無論經(jīng)歷什么耗時長問題卦停，Redlock 都能夠在第 3 步檢測出來
• 客戶端在拿到鎖之后向胡，發(fā)生 NPC恼蓬，那 Redlock、Zookeeper 都無能為力

所以僵芹，Redis 作者認為 Redlock 在保證時鐘正確的基礎(chǔ)上蓖宦，是可以保證正確性的晶密。

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

Redis 作者對于對方提出的 fecing token 機制，也提出了質(zhì)疑，主要分為 2 個問題蔫仙，這里最不宜理解，請跟緊我的思路战得。

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

例如茧彤，要操作 MySQL骡显，從鎖服務(wù)拿到一個遞增數(shù)字的 token，然后客戶端要帶著這個 token 去改 MySQL 的某一行曾掂，這就需要利用 MySQL 的「事物隔離性」來做惫谤。

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

但如果操作的不是 MySQL 呢？例如向磁盤上寫一個文件珠洗，或發(fā)起一個 HTTP 請求溜歪，那這個方案就無能為力了，這對要操作的資源服務(wù)器险污，提出了更高的要求痹愚。

也就是說，大部分要操作的資源服務(wù)器蛔糯，都是沒有這種互斥能力的拯腮。

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

所以，Redis 作者認為這個方案是站不住腳的淮逻。

第二琼懊，退一步講，即使 Redlock 沒有提供 fecing token 的能力爬早，但 Redlock 已經(jīng)提供了隨機值（就是前面講的 UUID）哼丈，利用這個隨機值，也可以達到與 fecing token 同樣的效果筛严。

如何做呢醉旦？

Redis 作者只是提到了可以完成 fecing token 類似的功能，但卻沒有展開相關(guān)細節(jié)，根據(jù)我查閱的資料车胡，大概流程應該如下檬输，如有錯誤，歡迎交流~

1. 客戶端使用 Redlock 拿到鎖
2. 客戶端在操作共享資源之前匈棘，先把這個鎖的 VALUE丧慈，在要操作的共享資源上做標記
3. 客戶端處理業(yè)務(wù)邏輯，最后主卫，在修改共享資源時逃默，判斷這個標記是否與之前一樣，一樣才修改（類似 CAS 的思路）

還是以 MySQL 為例簇搅，舉個例子就是這樣的：

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

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

可見筒主，這種方案依賴 MySQL 的事物機制，也達到對方提到的 fecing token 一樣的效果鸟蟹。

但這里還有個小問題乌妙，是網(wǎng)友參與問題討論時提出的：兩個客戶端通過這種方案，先「標記」再「檢查+修改」共享資源建钥，那這兩個客戶端的操作順序無法保證疤僭稀？

而用 Martin 提到的 fecing token熊经，因為這個 token 是單調(diào)遞增的數(shù)字泽艘，資源服務(wù)器可以拒絕小的 token 請求，保證了操作的「順序性」镐依！

Redis 作者對于這個問題做了不同的解釋匹涮，我覺得很有道理，他解釋道：分布式鎖的本質(zhì)槐壳，是為了「互斥」然低，只要能保證兩個客戶端在并發(fā)時，一個成功务唐，一個失敗就好了雳攘，不需要關(guān)心「順序性」。

前面 Martin 的質(zhì)疑中枫笛，一直很關(guān)心這個順序性問題吨灭，但 Redis 的作者的看法卻不同。

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

1喧兄、作者同意對方關(guān)于「時鐘跳躍」對 Redlock 的影響涩咖，但認為時鐘跳躍是可以避免的，取決于基礎(chǔ)設(shè)施和運維繁莹。

2、Redlock 在設(shè)計時特幔，充分考慮了 NPC 問題咨演，在 Redlock 步驟 3 之前出現(xiàn) NPC，可以保證鎖的正確性蚯斯，但在步驟 3 之后發(fā)生 NPC薄风，不止是 Redlock 有問題，其它分布式鎖服務(wù)同樣也有問題拍嵌，所以不在討論范疇內(nèi)遭赂。

是不是覺得很有意思？

在分布式系統(tǒng)中横辆，一個小小的鎖撇他，居然可能會遇到這么多問題場景，影響它的安全性狈蚤！

不知道你看完雙方的觀點困肩，更贊同哪一方的說法呢？

別急脆侮，后面我還會綜合以上論點锌畸，談?wù)勛约旱睦斫狻?/p>

好，講完了雙方對于 Redis 分布鎖的爭論靖避，你可能也注意到了潭枣，Martin 在他的文章中，推薦使用 Zookeeper 實現(xiàn)分布式鎖幻捏，認為它更安全盆犁，確實如此嗎？

基于 Zookeeper 的鎖安全嗎篡九？

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

1. 客戶端 1 和 2 都嘗試創(chuàng)建「臨時節(jié)點」，例如 /lock
2. 假設(shè)客戶端 1 先到達瓮下，則加鎖成功翰铡，客戶端 2 加鎖失敗
3. 客戶端 1 操作共享資源
4. 客戶端 1 刪除 /lock 節(jié)點，釋放鎖

你應該也看到了讽坏，Zookeeper 不像 Redis 那樣锭魔，需要考慮鎖的過期時間問題，它是采用了「臨時節(jié)點」路呜，保證客戶端 1 拿到鎖后迷捧，只要連接不斷织咧，就可以一直持有鎖。

而且漠秋，如果客戶端 1 異常崩潰了笙蒙，那么這個臨時節(jié)點會自動刪除，保證了鎖一定會被釋放庆锦。

不錯捅位，沒有鎖過期的煩惱，還能在異常時自動釋放鎖搂抒，是不是覺得很完美艇搀？

其實不然。

思考一下求晶，客戶端 1 創(chuàng)建臨時節(jié)點后焰雕，Zookeeper 是如何保證讓這個客戶端一直持有鎖呢？

原因就在于芳杏，客戶端 1 此時會與 Zookeeper 服務(wù)器維護一個 Session矩屁，這個 Session 會依賴客戶端「定時心跳」來維持連接。

如果 Zookeeper 長時間收不到客戶端的心跳爵赵，就認為這個 Session 過期了档插，也會把這個臨時節(jié)點刪除。

同樣地亚再，基于此問題郭膛，我們也討論一下 GC 問題對 Zookeeper 的鎖有何影響：

1. 客戶端 1 創(chuàng)建臨時節(jié)點 /lock 成功，拿到了鎖
2. 客戶端 1 發(fā)生長時間 GC
3. 客戶端 1 無法給 Zookeeper 發(fā)送心跳氛悬，Zookeeper 把臨時節(jié)點「刪除」
4. 客戶端 2 創(chuàng)建臨時節(jié)點 /lock 成功则剃，拿到了鎖
5. 客戶端 1 GC 結(jié)束，它仍然認為自己持有鎖（沖突）

可見如捅，即使是使用 Zookeeper棍现，也無法保證進程 GC、網(wǎng)絡(luò)延遲異常場景下的安全性镜遣。

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

所以寓辱，這里我們就能得出結(jié)論了：一個分布式鎖艘绍，在極端情況下，不一定是安全的秫筏。

如果你的業(yè)務(wù)數(shù)據(jù)非常敏感诱鞠，在使用分布式鎖時挎挖，一定要注意這個問題，不能假設(shè)分布式鎖 100% 安全航夺。

好蕉朵，現(xiàn)在我們來總結(jié)一下 Zookeeper 在使用分布式鎖時優(yōu)劣：

Zookeeper 的優(yōu)點：

1. 不需要考慮鎖的過期時間
2. watch 機制，加鎖失敗阳掐，可以 watch 等待鎖釋放始衅，實現(xiàn)樂觀鎖

但它的劣勢是：

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

我對分布式鎖的理解

好了锚烦，前面詳細介紹了基于 Redis 的 Redlock 和 Zookeeper 實現(xiàn)的分布鎖，在各種異常情況下的安全性問題帝雇，下面我想和你聊一聊我的看法涮俄，僅供參考，不喜勿噴尸闸。

1) 到底要不要用 Redlock彻亲？

前面也分析了，Redlock 只有建立在「時鐘正確」的前提下吮廉，才能正常工作苞尝，如果你可以保證這個前提，那么可以拿來使用宦芦。

但保證時鐘正確宙址，我認為并不是你想的那么簡單就能做到的。

第一调卑，從硬件角度來說抡砂，時鐘發(fā)生偏移是時有發(fā)生，無法避免的恬涧。

例如注益，CPU 溫度、機器負載溯捆、芯片材料都是有可能導致時鐘發(fā)生偏移丑搔。

第二，從我的工作經(jīng)歷來說提揍，曾經(jīng)就遇到過時鐘錯誤啤月、運維暴力修改時鐘的情況發(fā)生，進而影響了系統(tǒng)的正確性劳跃，所以顽冶，人為錯誤也是很難完全避免的。

所以售碳，我對 Redlock 的個人看法是强重，盡量不用它绞呈，而且它的性能不如單機版 Redis，部署成本也高间景，我還是會優(yōu)先考慮使用 Redis「主從+哨兵」的模式佃声，實現(xiàn)分布式鎖。

那正確性如何保證呢倘要？第二點給你答案圾亏。

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

在分析 Martin 觀點時封拧，它提到了 fecing token 的方案志鹃，給我了很大的啟發(fā)，雖然這種方案有很大的局限性泽西，但對于保證「正確性」的場景曹铃，是一個非常好的思路。

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

1陕见、使用分布式鎖，在上層完成「互斥」目的味抖，雖然極端情況下鎖會失效评甜，但它可以最大程度把并發(fā)請求阻擋在最上層，減輕操作資源層的壓力仔涩。

2忍坷、但對于要求數(shù)據(jù)絕對正確的業(yè)務(wù)，在資源層一定要做好「兜底」熔脂，設(shè)計思路可以借鑒 fecing token 的方案來做承匣。

兩種思路結(jié)合，我認為對于大多數(shù)業(yè)務(wù)場景锤悄，已經(jīng)可以滿足要求了韧骗。

總結(jié)

好了，總結(jié)一下零聚。

這篇文章袍暴，我們主要探討了基于 Redis 實現(xiàn)的分布式鎖，究竟是否安全這個問題隶症。

從最簡單分布式鎖的實現(xiàn)政模，到處理各種異常場景，再到引出 Redlock蚂会，以及兩個分布式專家的辯論淋样，得出了 Redlock 的適用場景。

最后胁住，我們還對比了 Zookeeper 在做分布式鎖時趁猴，可能會遇到的問題刊咳，以及與 Redis 的差異。

這里我把這些內(nèi)容總結(jié)成了思維導圖儡司，方便你理解娱挨。

后記

這篇文章的信息量其實是非常大的，我覺得應該把分布鎖的問題捕犬，徹底講清楚了跷坝。

如果你沒有理解，我建議你多讀幾遍碉碉，并在腦海中構(gòu)建各種假定的場景柴钻，反復思辨。

在寫這篇文章時垢粮，我又重新研讀了兩位大神關(guān)于 Redlock 爭辯的這兩篇文章贴届，可謂是是收獲滿滿，在這里也分享一些心得給你足丢。

1粱腻、在分布式系統(tǒng)環(huán)境下庇配，看似完美的設(shè)計方案斩跌，可能并不是那么「嚴絲合縫」，如果稍加推敲捞慌，就會發(fā)現(xiàn)各種問題耀鸦。所以，在思考分布式系統(tǒng)問題時啸澡，一定要謹慎再謹慎袖订。

2、從 Redlock 的爭辯中嗅虏，我們不要過多關(guān)注對錯洛姑，而是要多學習大神的思考方式，以及對一個問題嚴格審查的嚴謹精神皮服。

最后楞艾，用 Martin 在對于 Redlock 爭論過后，寫下的感悟來結(jié)尾：

“前人已經(jīng)為我們創(chuàng)造出了許多偉大的成果：站在巨人的肩膀上龄广，我們可以才得以構(gòu)建更好的軟件硫眯。無論如何，通過爭論和檢查它們是否經(jīng)得起別人的詳細審查择同，這是學習過程的一部分两入。但目標應該是獲取知識，而不是為了說服別人敲才，讓別人相信你是對的裹纳。有時候择葡，那只是意味著停下來，好好地想一想痊夭。”

共勉刁岸。