面試官：談談分布式鎖的實現

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

什么是分布式鎖

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

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

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

分布式鎖的場景

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

分布式鎖的特點

1、互斥性

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

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

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

3、容錯性

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

4、解鎖

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

分布式鎖的實現

• 基于redis實現

• 基于mysql樂觀鎖實現

• 基于zookeeper實現

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

加鎖實現方式

常用redis命令

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

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

• getset：設置指定key的值，并返回key的舊值

錯誤示例

1、通過setnx、expire實現

實現思路：在當前鎖沒有被占用的情況下，加鎖成功后，給鎖設置一個過期時間。

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

2、將鎖的值設為過期時間，通過鎖的值對比實現

這段代碼實現的缺點是：

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

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

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

正確示例

參數說明：

• nx：SET IF NOT EXIST，即當key不存在時，進行set操作，若key已經存在，則不做任何操作

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

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

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

解鎖實現方式

常用redis命令

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

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

錯誤示例

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

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

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

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

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

正確示例

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

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

思考

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

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

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

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

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

Redis cluster集群圖

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

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

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

總結

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

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

3、正確加鎖方式：

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

4、正確解鎖方式：

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

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