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

什么是分布式鎖

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

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

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

分布式鎖的場景

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

分布式鎖的特點

1、互斥性

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

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

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

3、容錯性

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

4、解鎖

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

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

• 基于redis實現(xiàn)

• 基于mysql樂觀鎖實現(xiàn)

• 基于zookeeper實現(xiàn)

在這篇文章中，我們重點來講述如何通過redis來實現(xiàn)分布式鎖。

加鎖實現(xiàn)方式

常用redis命令

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

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

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

錯誤示例

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

實現(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è)為過期時間，通過鎖的值對比實現(xiàn)

這段代碼實現(xià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ù)，因此我們在實現(xiàn)分布式鎖的時候就可以進(jìn)行原子操作，同時加鎖操作也變得簡單。

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

解鎖實現(xiàn)方式

常用redis命令

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

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

錯誤示例

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

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

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

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

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

正確示例

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

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

思考

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

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

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

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

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

Redis cluster集群圖

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

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

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

總結(jié)

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

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

3、正確加鎖方式：

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

4、正確解鎖方式：

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

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