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

什么是分布式鎖

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

小萊去網(wǎng)吧打游戲，路上碰巧遇到了同學(xué)小王和小丁，三人同時來到網(wǎng)吧前臺表示都想在包廂里上網(wǎng)。但是包廂只有一個，同一時間也只能容納一人，前臺MM很為難。突然，前臺MM心生一計，將一枚硬幣拋于空中，讓他們?nèi)送瑫r爭搶，誰能搶到誰去包廂。只見小萊眼疾手快最終將硬幣據(jù)為己有，看著不甘的小王和小丁，哼著小曲進(jìn)了包廂.....

在這個例子中，小萊、小王和小丁可以看成三個獨(dú)立分布的客戶端（三個獨(dú)立系統(tǒng)），小萊在包廂上網(wǎng)的時間看作鎖的時間，包廂可以看作同一資源。同一時刻三人都想去包廂（即都想訪問同一資源），那么硬幣就可以作為一把分布式鎖限制同一時刻共享包廂的人員。

分布式鎖的場景

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

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

1、互斥性

任意時刻，只有一個客戶端能夠持有鎖。

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

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

3、容錯性

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

4、解鎖

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

分布式鎖的實(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不存在時，為key設(shè)置指定值

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

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

錯誤示例

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

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

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

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

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

1. 需要分布式下每個客戶端的時間保持一致；

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

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

正確示例

參數(shù)說明：

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

• px：給key加一個過期時間，單位ms

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

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

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

常用redis命令

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

• pttl：以毫秒為單位返回key的剩余過期時間

錯誤示例

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

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

2、有人可能會說，加鎖時給每個客戶端分配一個唯一的value值，每次釋放鎖前把鎖的值與客戶端傳過來的值做對比，相同再刪除不就行了，即：

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

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

正確示例

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

通過redis里eval命令操作lua代碼，這樣可以確保在解鎖時保持原子性，而不會因?yàn)檫M(jìn)程的崩潰導(dǎo)致解鎖失敗。

思考

到這里我們就完成了分布式鎖的實(shí)現(xiàn)，請繼續(xù)思考：

一、當(dāng)在集群中，某個master節(jié)點(diǎn)宕機(jī)后，master數(shù)據(jù)未及時同步至slave節(jié)點(diǎn)時，上述示例是否還能滿足當(dāng)前場景？此時會發(fā)生什么樣的情況？又該如何來解決？

上邊講述的示例適用于單實(shí)例或?qū)I(yè)務(wù)要求性不高的情況，當(dāng)在集群上實(shí)現(xiàn)分布式鎖的時候，master節(jié)點(diǎn)宕機(jī)且數(shù)據(jù)未同步至slave節(jié)點(diǎn)時，此時就會出現(xiàn)多個客戶端擁有一把鎖的情況，失去了鎖的互斥性原則。

基于此，redis官方提出了RedLock的實(shí)現(xiàn)方案，核心思想是同時使用多個Redis Master來冗余，且這些節(jié)點(diǎn)是完全獨(dú)立的，也不需要對這些節(jié)點(diǎn)之間的數(shù)據(jù)進(jìn)行同步。獲取集群中多數(shù)master節(jié)點(diǎn)上的鎖，同時全部獲取，否則全部釋放。

例如下圖的集群中，同時在一半以上（2個master）的master上加鎖，如果其中某一個master宕機(jī)，客戶端仍然可以獲取到鎖。

Redis cluster集群圖

二、業(yè)務(wù)未處理完面臨鎖時間到期如何處理？

還是開頭那個例子，小萊在包廂里打游戲，任務(wù)做到一半，時間到了，這時怎么辦呢？有經(jīng)驗(yàn)的同學(xué)第一反應(yīng)肯定是去續(xù)費(fèi)。

那么對應(yīng)到鎖的應(yīng)用上也是這樣，當(dāng)占有鎖的時間快到了但是此時業(yè)務(wù)未處理完，可以延長鎖的過期時間，即鎖支持可重入。

總結(jié)

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

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

3、正確加鎖方式：

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

4、正確解鎖方式：

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

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