面試官:談?wù)劮植际芥i的實(shí)現(xiàn)
最近小萊去大廠面試,最終掛在了分布式鎖上,于是回來后認(rèn)真整理了這篇文章,以期下次面試遇到同樣的問題時(shí)一雪前恥......
什么是分布式鎖
分布式鎖是控制分布式系統(tǒng)之間同步訪問共享資源的一種方式。舉個(gè)通俗易懂的例子:網(wǎng)吧打游戲。
小萊去網(wǎng)吧打游戲,路上碰巧遇到了同學(xué)小王和小丁,三人同時(shí)來到網(wǎng)吧前臺(tái)表示都想在包廂里上網(wǎng)。但是包廂只有一個(gè),同一時(shí)間也只能容納一人,前臺(tái)MM很為難。突然,前臺(tái)MM心生一計(jì),將一枚硬幣拋于空中,讓他們?nèi)送瑫r(shí)爭(zhēng)搶,誰(shuí)能搶到誰(shuí)去包廂。只見小萊眼疾手快最終將硬幣據(jù)為己有,看著不甘的小王和小丁,哼著小曲進(jìn)了包廂.....
在這個(gè)例子中,小萊、小王和小丁可以看成三個(gè)獨(dú)立分布的客戶端(三個(gè)獨(dú)立系統(tǒng)),小萊在包廂上網(wǎng)的時(shí)間看作鎖的時(shí)間,包廂可以看作同一資源。同一時(shí)刻三人都想去包廂(即都想訪問同一資源),那么硬幣就可以作為一把分布式鎖限制同一時(shí)刻共享包廂的人員。
分布式鎖的場(chǎng)景
當(dāng)多個(gè)機(jī)器(多個(gè)進(jìn)程)對(duì)同一數(shù)據(jù)進(jìn)行修改時(shí),并且要求這個(gè)修改是原子性的,那么就要用到分布式鎖。例如:秒殺時(shí)解決庫(kù)存超賣問題。
分布式鎖的特點(diǎn)
1、互斥性
任意時(shí)刻,只有一個(gè)客戶端能夠持有鎖。
2、不會(huì)發(fā)送死鎖
即使有一個(gè)客戶端在持有鎖的期間崩潰而沒有主動(dòng)解鎖,也能保證后續(xù)其他客戶端能加鎖。
3、容錯(cuò)性
只要大部分的redis節(jié)點(diǎn)正常運(yùn)行,客戶端就可以加鎖和解鎖。
4、解鎖
加鎖和解鎖必須為同一個(gè)客戶端,客戶端不能解鎖他人的鎖。
分布式鎖的實(shí)現(xiàn)
基于redis實(shí)現(xiàn)
基于mysql樂觀鎖實(shí)現(xiàn)
基于zookeeper實(shí)現(xiàn)
在這篇文章中,我們重點(diǎn)來講述如何通過redis來實(shí)現(xiàn)分布式鎖。
加鎖實(shí)現(xiàn)方式
常用redis命令
setnx:在指定的key不存在時(shí),為key設(shè)置指定值
expire:設(shè)置key過期時(shí)間,單位以秒計(jì)
getset:設(shè)置指定key的值,并返回key的舊值
錯(cuò)誤示例
1、通過setnx、expire實(shí)現(xiàn)
實(shí)現(xiàn)思路:在當(dāng)前鎖沒有被占用的情況下,加鎖成功后,給鎖設(shè)置一個(gè)過期時(shí)間。
這乍看沒有什么問題,但是仔細(xì)思考之后就會(huì)發(fā)現(xiàn)由于setnx/expire不具有原子性,某一時(shí)刻進(jìn)程在執(zhí)行expire前突然崩潰,就會(huì)導(dǎo)致該鎖永久存在,后續(xù)進(jìn)程在獲取鎖時(shí)發(fā)現(xiàn)鎖已被占用,從而導(dǎo)致無法加鎖。
2、將鎖的值設(shè)為過期時(shí)間,通過鎖的值對(duì)比實(shí)現(xiàn)
這段代碼實(shí)現(xiàn)的缺點(diǎn)是:
需要分布式下每個(gè)客戶端的時(shí)間保持一致;
鎖快過期時(shí),多個(gè)客戶端同時(shí)執(zhí)行g(shù)etSet,雖然最終只有一個(gè)客戶端可以加鎖,但該客戶端鎖的過期時(shí)間可能被其他客戶端覆蓋;
不具備擁有者標(biāo)識(shí),任何客戶端都可以解鎖。
正確示例
參數(shù)說明:
nx:SET IF NOT EXIST,即當(dāng)key不存在時(shí),進(jìn)行set操作,若key已經(jīng)存在,則不做任何操作
px:給key加一個(gè)過期時(shí)間,單位ms
redis2.8版本后,set里提供了px參數(shù),因此我們?cè)趯?shí)現(xiàn)分布式鎖的時(shí)候就可以進(jìn)行原子操作,同時(shí)加鎖操作也變得簡(jiǎn)單。
通過上述示例,我們已經(jīng)清楚地知道了加鎖的實(shí)現(xiàn)方式,但是解鈴還須系鈴人,解鎖如何實(shí)現(xiàn)呢?
解鎖實(shí)現(xiàn)方式
常用redis命令
del:用于刪除已存在的鍵
pttl:以毫秒為單位返回key的剩余過期時(shí)間
錯(cuò)誤示例
1、最常見的一種錯(cuò)誤解鎖方式是直接通過刪除del來進(jìn)行的:
這種方式的錯(cuò)誤在于不具有擁有者標(biāo)識(shí),任何客戶端都可以隨時(shí)進(jìn)行解鎖。
2、有人可能會(huì)說,加鎖時(shí)給每個(gè)客戶端分配一個(gè)唯一的value值,每次釋放鎖前把鎖的值與客戶端傳過來的值做對(duì)比,相同再刪除不就行了,即:
這種方式確實(shí)在一般情況下能夠解決鎖被其他客戶端隨意釋放的問題,但是這樣實(shí)現(xiàn)會(huì)有什么問題呢?答案是當(dāng)客戶端A在執(zhí)行del之前,鎖突然過期了,此時(shí)客戶端B加鎖成功,然后客戶端A執(zhí)行del操作則會(huì)將客戶端B的鎖解除。這還是因?yàn)閯h除不具有原子性。
注:在這里還有一種解決臨界條件下客戶端A鎖被其他客戶端釋放的方式,只是對(duì)性能可能有一些影響:在del前,我們可以先判斷鎖的過期時(shí)間,如果當(dāng)前時(shí)間不小于10ms(根據(jù)自己的業(yè)務(wù)而定)的話可以操作del刪除,否則自然釋放,即:
正確示例
鎖的釋放包含了get、判斷、del三個(gè)步驟。如果不能保證三個(gè)步驟的原子性,分布式鎖就會(huì)有并發(fā)問題。
通過redis里eval命令操作lua代碼,這樣可以確保在解鎖時(shí)保持原子性,而不會(huì)因?yàn)檫M(jìn)程的崩潰導(dǎo)致解鎖失敗。
思考
到這里我們就完成了分布式鎖的實(shí)現(xiàn),請(qǐng)繼續(xù)思考:
一、當(dāng)在集群中,某個(gè)master節(jié)點(diǎn)宕機(jī)后,master數(shù)據(jù)未及時(shí)同步至slave節(jié)點(diǎn)時(shí),上述示例是否還能滿足當(dāng)前場(chǎng)景?此時(shí)會(huì)發(fā)生什么樣的情況?又該如何來解決?
上邊講述的示例適用于單實(shí)例或?qū)I(yè)務(wù)要求性不高的情況,當(dāng)在集群上實(shí)現(xiàn)分布式鎖的時(shí)候,master節(jié)點(diǎn)宕機(jī)且數(shù)據(jù)未同步至slave節(jié)點(diǎn)時(shí),此時(shí)就會(huì)出現(xiàn)多個(gè)客戶端擁有一把鎖的情況,失去了鎖的互斥性原則。
基于此,redis官方提出了RedLock的實(shí)現(xiàn)方案,核心思想是同時(shí)使用多個(gè)Redis Master來冗余,且這些節(jié)點(diǎn)是完全獨(dú)立的,也不需要對(duì)這些節(jié)點(diǎn)之間的數(shù)據(jù)進(jìn)行同步。獲取集群中多數(shù)master節(jié)點(diǎn)上的鎖,同時(shí)全部獲取,否則全部釋放。
例如下圖的集群中,同時(shí)在一半以上(2個(gè)master)的master上加鎖,如果其中某一個(gè)master宕機(jī),客戶端仍然可以獲取到鎖。
Redis cluster集群圖
二、業(yè)務(wù)未處理完面臨鎖時(shí)間到期如何處理?
還是開頭那個(gè)例子,小萊在包廂里打游戲,任務(wù)做到一半,時(shí)間到了,這時(shí)怎么辦呢?有經(jīng)驗(yàn)的同學(xué)第一反應(yīng)肯定是去續(xù)費(fèi)。
那么對(duì)應(yīng)到鎖的應(yīng)用上也是這樣,當(dāng)占有鎖的時(shí)間快到了但是此時(shí)業(yè)務(wù)未處理完,可以延長(zhǎng)鎖的過期時(shí)間,即鎖支持可重入。
總結(jié)
1、無論加鎖還是解鎖,都要確保原子性操作;
2、Redis分布式鎖要考慮單實(shí)例和多實(shí)例的情況;
3、正確加鎖方式:
如果當(dāng)前業(yè)務(wù)可容忍多個(gè)客戶端擁有一把鎖或保證master不會(huì)發(fā)生故障,在集群中也可以使用這種方式。
4、正確解鎖方式:
特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容,還沒關(guān)注的小伙伴,可以長(zhǎng)按關(guān)注一下:
長(zhǎng)按訂閱更多精彩▼
如有收獲,點(diǎn)個(gè)在看,誠(chéng)摯感謝
免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn),不代表本平臺(tái)立場(chǎng),如有問題,請(qǐng)聯(lián)系我們,謝謝!