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