最近小萊去大廠面試，最終掛在了分布式鎖上，于是回來(lái)后認(rèn)真整理了這篇文章，以期下次面試遇到同樣的問(wèn)題時(shí)一雪前恥......

什么是分布式鎖

分布式鎖是控制分布式系統(tǒng)之間同步訪問(wèn)共享資源的一種方式。舉個(gè)通俗易懂的例子：網(wǎng)吧打游戲。

小萊去網(wǎng)吧打游戲，路上碰巧遇到了同學(xué)小王和小丁，三人同時(shí)來(lái)到網(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í)刻三人都想去包廂（即都想訪問(wèn)同一資源），那么硬幣就可以作為一把分布式鎖限制同一時(shí)刻共享包廂的人員。

分布式鎖的場(chǎng)景

當(dāng)多個(gè)機(jī)器（多個(gè)進(jìn)程）對(duì)同一數(shù)據(jù)進(jìn)行修改時(shí)，并且要求這個(gè)修改是原子性的，那么就要用到分布式鎖。例如：秒殺時(shí)解決庫(kù)存超賣問(wèn)題。

分布式鎖的特點(diǎn)

1、互斥性

任意時(shí)刻，只有一個(gè)客戶端能夠持有鎖。

2、不會(huì)發(fā)送死鎖

即使有一個(gè)客戶端在持有鎖的期間崩潰而沒(méi)有主動(dòng)解鎖，也能保證后續(xù)其他客戶端能加鎖。

3、容錯(cuò)性

只要大部分的redis節(jié)點(diǎn)正常運(yùn)行，客戶端就可以加鎖和解鎖。

4、解鎖

加鎖和解鎖必須為同一個(gè)客戶端，客戶端不能解鎖他人的鎖。

分布式鎖的實(shí)現(xiàn)

• 基于redis實(shí)現(xiàn)

• 基于mysql樂(lè)觀鎖實(shí)現(xiàn)

• 基于zookeeper實(shí)現(xiàn)

在這篇文章中，我們重點(diǎn)來(lái)講述如何通過(guò)redis來(lái)實(shí)現(xiàn)分布式鎖。

加鎖實(shí)現(xiàn)方式

常用redis命令

• setnx：在指定的key不存在時(shí)，為key設(shè)置指定值

• expire：設(shè)置key過(guò)期時(shí)間，單位以秒計(jì)

• getset：設(shè)置指定key的值，并返回key的舊值

錯(cuò)誤示例

1、通過(guò)setnx、expire實(shí)現(xiàn)

實(shí)現(xiàn)思路：在當(dāng)前鎖沒(méi)有被占用的情況下，加鎖成功后，給鎖設(shè)置一個(gè)過(guò)期時(shí)間。

這乍看沒(méi)有什么問(wèn)題，但是仔細(xì)思考之后就會(huì)發(fā)現(xiàn)由于setnx/expire不具有原子性，某一時(shí)刻進(jìn)程在執(zhí)行expire前突然崩潰，就會(huì)導(dǎo)致該鎖永久存在，后續(xù)進(jìn)程在獲取鎖時(shí)發(fā)現(xiàn)鎖已被占用，從而導(dǎo)致無(wú)法加鎖。

2、將鎖的值設(shè)為過(guò)期時(shí)間，通過(guò)鎖的值對(duì)比實(shí)現(xiàn)

這段代碼實(shí)現(xiàn)的缺點(diǎn)是：

1. 需要分布式下每個(gè)客戶端的時(shí)間保持一致；

2. 鎖快過(guò)期時(shí)，多個(gè)客戶端同時(shí)執(zhí)行g(shù)etSet，雖然最終只有一個(gè)客戶端可以加鎖，但該客戶端鎖的過(guò)期時(shí)間可能被其他客戶端覆蓋；

3. 不具備擁有者標(biāo)識(shí)，任何客戶端都可以解鎖。

正確示例

參數(shù)說(shuō)明：

• nx：SET IF NOT EXIST，即當(dāng)key不存在時(shí)，進(jìn)行set操作，若key已經(jīng)存在，則不做任何操作

• px：給key加一個(gè)過(guò)期時(shí)間，單位ms

redis2.8版本后，set里提供了px參數(shù)，因此我們?cè)趯?shí)現(xiàn)分布式鎖的時(shí)候就可以進(jìn)行原子操作，同時(shí)加鎖操作也變得簡(jiǎn)單。

通過(guò)上述示例，我們已經(jīng)清楚地知道了加鎖的實(shí)現(xiàn)方式，但是解鈴還須系鈴人，解鎖如何實(shí)現(xiàn)呢？

解鎖實(shí)現(xiàn)方式

常用redis命令

• del：用于刪除已存在的鍵

• pttl：以毫秒為單位返回key的剩余過(guò)期時(shí)間

錯(cuò)誤示例

1、最常見的一種錯(cuò)誤解鎖方式是直接通過(guò)刪除del來(lái)進(jìn)行的：

這種方式的錯(cuò)誤在于不具有擁有者標(biāo)識(shí)，任何客戶端都可以隨時(shí)進(jìn)行解鎖。

2、有人可能會(huì)說(shuō)，加鎖時(shí)給每個(gè)客戶端分配一個(gè)唯一的value值，每次釋放鎖前把鎖的值與客戶端傳過(guò)來(lái)的值做對(duì)比，相同再刪除不就行了，即：

這種方式確實(shí)在一般情況下能夠解決鎖被其他客戶端隨意釋放的問(wèn)題，但是這樣實(shí)現(xiàn)會(huì)有什么問(wèn)題呢？答案是當(dāng)客戶端A在執(zhí)行del之前，鎖突然過(guò)期了，此時(shí)客戶端B加鎖成功，然后客戶端A執(zhí)行del操作則會(huì)將客戶端B的鎖解除。這還是因?yàn)閯h除不具有原子性。

注：在這里還有一種解決臨界條件下客戶端A鎖被其他客戶端釋放的方式，只是對(duì)性能可能有一些影響：在del前，我們可以先判斷鎖的過(guò)期時(shí)間，如果當(dāng)前時(shí)間不小于10ms（根據(jù)自己的業(yè)務(wù)而定）的話可以操作del刪除，否則自然釋放，即：

正確示例

鎖的釋放包含了get、判斷、del三個(gè)步驟。如果不能保證三個(gè)步驟的原子性，分布式鎖就會(huì)有并發(fā)問(wèn)題。

通過(guò)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ā)生什么樣的情況？又該如何來(lái)解決？

上邊講述的示例適用于單實(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來(lái)冗余，且這些節(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)鎖的過(guò)期時(shí)間，即鎖支持可重入。

總結(jié)

1、無(wú)論加鎖還是解鎖，都要確保原子性操作；

2、Redis分布式鎖要考慮單實(shí)例和多實(shí)例的情況；

3、正確加鎖方式：

如果當(dāng)前業(yè)務(wù)可容忍多個(gè)客戶端擁有一把鎖或保證master不會(huì)發(fā)生故障，在集群中也可以使用這種方式。

4、正確解鎖方式：

特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒(méi)關(guān)注的小伙伴，可以長(zhǎng)按關(guān)注一下：

長(zhǎng)按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝