Redis分布式鎖，你用對了嗎？
[導(dǎo)讀]廢話不多說，直接上硬核。今天我們就來聊聊分布式鎖。PART1.分布式鎖是什么？我們的手機有鎖、車有鎖、家門有鎖、貴重物品會鎖進保險箱?？梢哉f，鎖在我們生活中無處不在，時刻保護著我們的人身財產(chǎn)安全。在計算機領(lǐng)域也一樣，鎖可以理解為針對某項資源使用權(quán)限的管理，它通常用來控制共享資源，...
廢話不多說，直接上硬核。
今天我們就來聊聊分布式鎖。
PART1.分布式鎖是什么？
我們的手機有鎖、車有鎖、家門有鎖、貴重物品會鎖進保險箱?？梢哉f，鎖在我們生活中無處不在，時刻保護著我們的人身財產(chǎn)安全。
在計算機領(lǐng)域也一樣，鎖可以理解為針對某項資源使用權(quán)限的管理，它通常用來控制共享資源，比如一個進程內(nèi)有多個線程競爭一個數(shù)據(jù)的使用權(quán)限，解決方式之一就是加鎖。
那分布式鎖是什么呢？
顧名思義，分布式鎖就是分布式場景下的鎖，比如多臺不同機器上的進程，去競爭同一項資源，就是分布式鎖。
PART2.分布式鎖有哪些特性？
具備哪些特性的分布式鎖才是一個優(yōu)秀的分布式鎖？我認(rèn)為要從如下幾方面來看：
- 互斥性：鎖的目的是獲取資源的使用權(quán)，所以只讓一個競爭者持有鎖，這一點要盡可能保證；
- 安全性：避免死鎖情況發(fā)生。當(dāng)一個競爭者在持有鎖期間內(nèi)，由于意外崩潰而導(dǎo)致未能主動解鎖，其持有的鎖也能夠被正常釋放，并保證后續(xù)其它競爭者也能加鎖；
- 對稱性：同一個鎖，加鎖和解鎖必須是同一個競爭者。不能把其他競爭者持有的鎖給釋放了，這又稱為鎖的可重入性。
- 可靠性：需要有一定程度的異常處理能力、容災(zāi)能力。
PART3.分布式鎖的常用實現(xiàn)方式
分布式鎖，一般會依托第三方組件來實現(xiàn)，而利用Redis實現(xiàn)則是工作中應(yīng)用最多的一種。
今天，就讓我們從最基礎(chǔ)的步驟開始，依照分布式鎖的特性，層層遞進，步步完善，將它優(yōu)化到最優(yōu)，讓大家完整地了解如何用Redis來實現(xiàn)一個分布式鎖。
最簡化版本
首先，當(dāng)然是搭建一個最簡單的實現(xiàn)方式，直接用Redis的setnx命令，這個命令的語法是：setnx key value如果key不存在，則會將key設(shè)置為value，并返回1；如果key存在，不會有任務(wù)影響，返回0。基于這個特性，我們就可以用setnx實現(xiàn)加鎖的目的：通過setnx加鎖，加鎖之后其他服務(wù)無法加鎖，用完之后，再通過delete解鎖，深藏功與名。
支持過期時間
最簡化版本有一個問題：如果獲取鎖的服務(wù)掛掉了，那么鎖就一直得不到釋放，就像石沉大海，杳無音信。所以，我們需要一個超時來兜底。Redis中有expire命令，用來設(shè)置一個key的超時時間。但是setnx和expire不具備原子性，如果setnx獲取鎖之后，服務(wù)掛掉，依舊是泥牛入海。
很自然，我們會想到，set和expire，有沒有原子操作？
當(dāng)然有，Redis早就考慮到了這種場景，推出了如下執(zhí)行語句：set key value nx ex secondsnx表示具備setnx特定，ex表示增加了過期時間，最后一個參數(shù)就是過期時間的值。
能夠支持過期時間，目前這個鎖基本上是能用了。
但是存在一個問題：會存在服務(wù)A釋放掉服務(wù)B的鎖的可能。
加上owner
我們來試想一下如下場景：服務(wù)A獲取了鎖，由于業(yè)務(wù)流程比較長，或者網(wǎng)絡(luò)延遲、GC卡頓等原因，導(dǎo)致鎖過期，而業(yè)務(wù)還會繼續(xù)進行。這時候，業(yè)務(wù)B已經(jīng)拿到了鎖，準(zhǔn)備去執(zhí)行，這個時候服務(wù)A恢復(fù)過來并做完了業(yè)務(wù)，就會釋放鎖，而B卻還在繼續(xù)執(zhí)行。在真實的分布式場景中，可能存在幾十個競爭者，那么上述情況發(fā)生概率就很高，導(dǎo)致同一份資源頻繁被不同競爭者同時訪問，分布式鎖也就失去了意義。
引入Lua
加入owner后的版本可以稱得上是完善了嗎？還有沒有什么隱患呢？我也不賣關(guān)子了，到這一步其實還存在一個小問題，我們完整的流程是競爭者獲取鎖執(zhí)行任務(wù)，執(zhí)行完畢后檢查鎖是不是自己的，最后進行釋放。
流程一梳理，你們肯定明白了，執(zhí)行完畢后，檢查鎖，再釋放，這些操作不是原子化的。
可能鎖獲取時還是自己的，刪除時卻已經(jīng)是別人的了。這可怎么辦呢？
Redis可沒有直接提供這種場景原子化的操作啊。遇事不要慌，仔細(xì)想一想，Redis是不是還有個特性，專門整合原子操作，對，就是它——Lua。
Redis?Lua，可以說是專門為解決原子問題而生。
有了Lua的特性，Redis才真正在分布式鎖、秒殺等場景，有了用武之地，下面便是改造之后的流程：
其實到了這一步，分布式鎖的前三個特性：對稱性、安全性、可靠性，就滿足了?？梢哉f是一個可用的分布式鎖了，能滿足大多數(shù)場景的需要。
PART4.可靠性如何保證
分布式鎖的四大特性還剩下可靠性沒有解決。
針對一些異常場景，包括Redis掛掉了、業(yè)務(wù)執(zhí)行時間過長、網(wǎng)絡(luò)波動等情況，我們來一起分析如何處理。
容災(zāi)考慮
前面我們談及的內(nèi)容，基本是基于單機考慮的，如果Redis掛掉了，那鎖就不能獲取了。這個問題該如何解決呢？一般來說，有兩種方法：主從容災(zāi)和多級部署。
主從容災(zāi)
最簡單的一種方式，就是為Redis配置從節(jié)點，當(dāng)主節(jié)點掛了，用從節(jié)點頂包。但是主從切換，需要人工參與，會提高人力成本。不過Redis已經(jīng)有成熟的解決方案，也就是哨兵模式，可以靈活自動切換，不再需要人工介入。
通過增加從節(jié)點的方式，雖然一定程度解決了單點的容災(zāi)問題，但并不是盡善盡美的，由于同步有時延，Slave可能會損失掉部分?jǐn)?shù)據(jù)，分布式鎖可能失效，這就會發(fā)生短暫的多機獲取到執(zhí)行權(quán)限。
有沒有更可靠的辦法呢？
多機部署
如果對一致性的要求高一些，可以嘗試多機部署，比如Redis的RedLock，大概的思路就是多個機器，通常是奇數(shù)個，達到一半以上同意加鎖才算加鎖成功，這樣，可靠性會向ETCD靠近。現(xiàn)在假設(shè)有5個Redis主節(jié)點，基本保證它們不會同時宕掉，獲取鎖和釋放鎖的過程中，客戶端會執(zhí)行以下操作：
1.向5個Redis申請加鎖；
2.只要超過一半，也就是3個Redis返回成功，那么就是獲取到了鎖。如果超過一半失敗，需要向每個Redis發(fā)送解鎖命令；
3.由于向5個Redis發(fā)送請求，會有一定時耗，所以鎖剩余持有時間，需要減去請求時間。這個可以作為判斷依據(jù)，如果剩余時間已經(jīng)為0，那么也是獲取鎖失敗；
4.使用完成之后，向5個Redis發(fā)送解鎖請求。
這種模式的好處在于，如果掛了2臺Redis，整個集群還是可用的，給了運維更多時間來修復(fù)。
另外，多說一句，單點Redis的所有手段，這種多機模式都可以使用，比如為每個節(jié)點配置哨兵模式，由于加鎖是一半以上同意就成功，那么如果單個節(jié)點進行了主從切換，單個節(jié)點數(shù)據(jù)的丟失，就不會讓鎖失效了。這樣增強了可靠性。
可靠性深究是不是有RedLock，就一定能保證可靠的分布式鎖？
這里我先說結(jié)論：由于分布式系統(tǒng)中的三大困境（簡稱NPC），所以沒有完全可靠的分布式鎖！
讓我們來看看RedLock在NPC下的表現(xiàn)。
N：Network Delay（網(wǎng)絡(luò)延遲）當(dāng)分布式鎖獲得返回包的時間過長，此時可能雖然加鎖成功，但是已經(jīng)時過境遷，鎖可能很快過期。RedLock算了做了些考量，也就是前面所說的鎖剩余持有時間，需要減去請求時間，如此一來，就可以一定程度解決網(wǎng)絡(luò)延遲的問題。
P：Process Pause（進程暫停）比如發(fā)生GC，獲取鎖之后GC了，處于GC執(zhí)行中，然后鎖超時。
其他鎖獲取，這種情況幾乎無解。這時候GC回來了，那么兩個進程就獲取到了同一個分布式鎖。
也許你會說，在GC回來之后，可以再去查一次?。?/span>
這里有兩個問題，首先你怎么知道GC回來了？這個可以在做業(yè)務(wù)之前，通過時間，進行一個粗略判斷，但也是很吃場景經(jīng)驗的；第二，如果你判斷的時候是ok的，但是判斷完GC了呢？這點RedLock是無法解決的。
C：Clock Drift（時鐘漂移）
如果競爭者A，獲得了RedLock，在5臺分布式機器上都加上鎖。為了方便分析，我們直接假設(shè)5臺機器都發(fā)生了時鐘漂移，鎖瞬間過期了。這時候競爭者B拿到了鎖，此時A和B拿到了相同的執(zhí)行權(quán)限。
根據(jù)上述的分析，可以看出，RedLock也不能扛住NPC的挑戰(zhàn)，因此，單單從分布式鎖本身出發(fā)，完全可靠是不可能的。要實現(xiàn)一個相對可靠的分布式鎖機制，還是需要和業(yè)務(wù)的配合，業(yè)務(wù)本身要冪等可重入，這樣的設(shè)計可以省卻很多麻煩。
PART5.復(fù)盤
我們圍繞互斥性、安全性、對稱性層層遞進，實現(xiàn)了一個Redis分布式鎖，這樣的架構(gòu)在大多數(shù)業(yè)務(wù)場景都是完全夠用的。
同時，我們也針對可靠性，探討了主從容災(zāi)、Red Lock等解決方案，并分析了NPC異常場景，了解到分布式鎖在什么情況會失去作用，這些知識在實際的業(yè)務(wù)中都非常實用，能夠在實際開發(fā)中做出正確的決策。
建議對分布式鎖不要強依賴，沒有絕對可靠的分布式鎖，分布式鎖需要與業(yè)務(wù)的聯(lián)動配合更加切實可行，脫離了業(yè)務(wù)，就是空中樓閣，不著實地。
圖解 Reids 系列文章
- 先更新數(shù)據(jù)庫，還是先更新緩存？
- 主從復(fù)制
- RDB 和 AOF 讀者問題答疑
- RDB 快照
- AOF 日志
- 緩存雪崩、擊穿、穿透
下載文檔
