大家好，我是小?。

作為一個(gè)后臺(tái)開(kāi)發(fā)，不管是工作還是面試中，分布式一直是一個(gè)讓人又愛(ài)又恨的話題。它如同一座神秘的迷宮，時(shí)而讓你迷失方向，時(shí)而又為你揭示出令人驚嘆的寶藏。

今天，讓我們來(lái)聊聊分布式領(lǐng)域中那位不太引人注意卻功不可沒(méi)的角色，它就像是分布式系統(tǒng)的守衛(wèi)，保護(hù)著資源不被隨意訪問(wèn)——這就是分布式鎖！

想象一下，如果沒(méi)有分布式鎖，多個(gè)分布式節(jié)點(diǎn)同時(shí)涌入一個(gè)共享資源的訪問(wèn)時(shí)，就像一群饑腸轆轆的狼匯聚在一塊肉前，誰(shuí)都想咬一口，最后弄得肉丟了個(gè)精光，大家都吃不上。

而有了分布式鎖，就像給這塊肉上了道堅(jiān)固的城墻，只有一只狼能夠穿越，享受美味。

那它具體是怎么做的呢？這篇文章中，小?將帶大家一起了解分布式鎖是如何解決分布式系統(tǒng)中的并發(fā)問(wèn)題的。

什么是分布式鎖？

在分布式系統(tǒng)中，分布式鎖是一種機(jī)制，用于協(xié)調(diào)多個(gè)節(jié)點(diǎn)上的并發(fā)訪問(wèn)共享資源。

這個(gè)共享資源可以是數(shù)據(jù)庫(kù)、文件、緩存或任何需要互斥訪問(wèn)的數(shù)據(jù)或資源。分布式鎖確保了在任何給定時(shí)刻只有一個(gè)節(jié)點(diǎn)能夠?qū)Y源進(jìn)行操作，從而保持了數(shù)據(jù)的一致性和可靠性。

為什么要使用分布式鎖？

1. 數(shù)據(jù)一致性

在分布式環(huán)境中，多個(gè)節(jié)點(diǎn)同時(shí)訪問(wèn)共享資源可能導(dǎo)致數(shù)據(jù)不一致的問(wèn)題。分布式鎖可以防止這種情況發(fā)生，確保數(shù)據(jù)的一致性。

2. 防止競(jìng)爭(zhēng)條件

多個(gè)節(jié)點(diǎn)并發(fā)訪問(wèn)共享資源時(shí)可能出現(xiàn)競(jìng)爭(zhēng)條件，這會(huì)導(dǎo)致不可預(yù)測(cè)的結(jié)果。分布式鎖可以有效地防止競(jìng)爭(zhēng)條件，確保操作按照預(yù)期順序執(zhí)行。

3. 限制資源的訪問(wèn)

有些資源可能需要限制同時(shí)訪問(wèn)的數(shù)量，以避免過(guò)載或資源浪費(fèi)。分布式鎖可以幫助控制資源的訪問(wèn)。

分布式鎖要解決的問(wèn)題

分布式鎖的核心問(wèn)題是如何在多個(gè)節(jié)點(diǎn)之間協(xié)調(diào)，以確保只有一個(gè)節(jié)點(diǎn)可以獲得鎖，而其他節(jié)點(diǎn)必須等待。

這涉及到以下關(guān)鍵問(wèn)題：

1. 互斥性

只有一個(gè)節(jié)點(diǎn)能夠獲得鎖，其他節(jié)點(diǎn)必須等待。這確保了資源的互斥訪問(wèn)。

2. 可重入性

指的是在同一線程內(nèi)，外層函數(shù)獲得鎖之后，內(nèi)層遞歸函數(shù)仍然可以獲取到該鎖。

說(shuō)白了就是同一個(gè)線程再次進(jìn)入同樣代碼時(shí)，可以再次拿到該鎖。它的作用是：防止在同一線程中多次獲取鎖產(chǎn)生競(jìng)性條件而導(dǎo)致死鎖發(fā)生。

3. 超時(shí)釋放

確保即使節(jié)點(diǎn)在業(yè)務(wù)過(guò)程中發(fā)生故障，鎖也會(huì)被超時(shí)釋放，既能防止不必要的線程等待和資源浪費(fèi)，也能避免死鎖。

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

在分布式系統(tǒng)中，有多種方式可以實(shí)現(xiàn)分布式鎖，就像是鎖的品種不同，每種鎖都有自己的特點(diǎn)。

• 有基于數(shù)據(jù)庫(kù)的鎖，就像是廚師們用餐具把菜肴鎖在柜子里，每個(gè)人都得排隊(duì)去取。
• 還有基于 ZooKeeper 的鎖，它像是整個(gè)餐廳的門(mén)衛(wèi)，只允許一個(gè)人進(jìn)去，其他人只能在門(mén)口等。
• 最后，還有基于緩存的鎖，就像是一位服務(wù)員用號(hào)碼牌幫你占座，先到先得。

1. 基于數(shù)據(jù)庫(kù)的分布式鎖

使用數(shù)據(jù)庫(kù)表中的一行記錄作為鎖，通過(guò)事務(wù)來(lái)獲取和釋放鎖。

例如，使用 MySQL 來(lái)實(shí)現(xiàn)事務(wù)鎖。首先創(chuàng)建一張簡(jiǎn)單表，在某一個(gè)字段上創(chuàng)建唯一索引（保證多個(gè)請(qǐng)求新增字段時(shí)，只有一個(gè)請(qǐng)求可成功）。

CREATE TABLE `user` (  
  `id` bigint(20) NOT NULL AUTO_INCREMENT,  
  `uname` varchar(255) DEFAULT NULL,  
  PRIMARY KEY (`id`),  
  UNIQUE KEY `name` (`uname`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4

當(dāng)需要獲取分布式鎖時(shí)，執(zhí)行以下語(yǔ)句：

INSERT INTO `user` (uname) VALUES ('unique_key')

由于 name 字段上加了唯一索引，所以當(dāng)多個(gè)請(qǐng)求提交 insert 語(yǔ)句時(shí)，只有一個(gè)請(qǐng)求可成功。

使用 MySQL 實(shí)現(xiàn)分布式鎖的優(yōu)點(diǎn)是可靠性高，但性能較差，而且這把鎖是非重入的，同一個(gè)線程在沒(méi)有釋放鎖之前無(wú)法獲得該鎖。

2. 基于ZooKeeper的分布式鎖

Zookeeper（簡(jiǎn)稱(chēng) zk）是一個(gè)為分布式應(yīng)用提供一致性服務(wù)的中間組件，其內(nèi)部是一個(gè)分層的文件系統(tǒng)目錄樹(shù)結(jié)構(gòu)。

zk 規(guī)定其某一個(gè)目錄下只能有唯一的一個(gè)文件名，其分布式鎖的實(shí)現(xiàn)方式如下：

1. 創(chuàng)建一個(gè)鎖目錄（ZNode）：首先，在 zk 中創(chuàng)建一個(gè)專(zhuān)門(mén)用于存儲(chǔ)鎖的目錄，通常稱(chēng)為鎖根節(jié)點(diǎn)。這個(gè)目錄將包含所有獲取鎖的請(qǐng)求以及用于鎖協(xié)調(diào)的節(jié)點(diǎn)。
2. 獲取鎖：當(dāng)一個(gè)節(jié)點(diǎn)想要獲取鎖時(shí)，它會(huì)在鎖目錄下創(chuàng)建一個(gè)臨時(shí)順序節(jié)點(diǎn)（Ephemeral Sequential Node）。zk 會(huì)為每個(gè)節(jié)點(diǎn)分配一個(gè)唯一的序列號(hào)，并根據(jù)序列號(hào)的大小來(lái)確定鎖的獲取順序。
3. 查看是否獲得鎖：節(jié)點(diǎn)在創(chuàng)建臨時(shí)順序節(jié)點(diǎn)后，需要檢查自己的節(jié)點(diǎn)是否是鎖目錄中序列號(hào)最小的節(jié)點(diǎn)。如果是，表示節(jié)點(diǎn)獲得了鎖；如果不是，則節(jié)點(diǎn)需要監(jiān)聽(tīng)比它序列號(hào)小的節(jié)點(diǎn)的刪除事件。
4. 監(jiān)聽(tīng)鎖釋放：如果一個(gè)節(jié)點(diǎn)沒(méi)有獲得鎖，它會(huì)設(shè)置一個(gè)監(jiān)聽(tīng)器來(lái)監(jiān)視比它序列號(hào)小的節(jié)點(diǎn)的刪除事件。一旦前一個(gè)節(jié)點(diǎn)（序列號(hào)小的節(jié)點(diǎn)）釋放了鎖，zk 會(huì)通知等待的節(jié)點(diǎn)。
5. 釋放鎖：當(dāng)一個(gè)節(jié)點(diǎn)完成了對(duì)共享資源的操作后，它會(huì)刪除自己創(chuàng)建的臨時(shí)節(jié)點(diǎn)，這將觸發(fā) zk 通知等待的節(jié)點(diǎn)。

zk 分布式鎖提供了良好的一致性和可用性，但部署和維護(hù)較為復(fù)雜，需要仔細(xì)處理各種邊界情況，例如節(jié)點(diǎn)的創(chuàng)建、刪除、網(wǎng)絡(luò)分區(qū)等。

而且 zk 實(shí)現(xiàn)分布式鎖的性能不太好，主要是獲取和釋放鎖都需要在集群的 Leader 節(jié)點(diǎn)上執(zhí)行，同步較慢。

3. 基于緩存的分布式鎖

使用分布式緩存，如 Redis 或 Memcached，來(lái)存儲(chǔ)鎖信息，緩存方式性能較高，但需要處理分布式緩存的高可用性和一致性。

接下來(lái)，我們?cè)敿?xì)討論一下在 Redis 中如何設(shè)計(jì)一個(gè)高可用的分布式鎖以及可能會(huì)遇到的幾個(gè)問(wèn)題，包括：

1. 死鎖問(wèn)題
2. 鎖提前釋放
3. 鎖被其它線程誤刪
4. 高可用問(wèn)題

1）死鎖問(wèn)題

早期版本的 redis 沒(méi)有 setnx 命令在寫(xiě) key 時(shí)直接設(shè)置超時(shí)參數(shù)，需要用 expire 命令單獨(dú)對(duì)鎖設(shè)置過(guò)期時(shí)間，這可能會(huì)導(dǎo)致死鎖問(wèn)題。

比如，設(shè)置鎖的過(guò)期時(shí)間執(zhí)行失敗了，導(dǎo)致后來(lái)的搶鎖都會(huì)失敗。

Lua腳本或SETNX

為了保證原子性，我們可以使用 Lua 腳本，保證SETNX + EXPIRE兩條指令的原子性，我們還可以巧用Redis 的 SET 指令擴(kuò)展參數(shù)：SET key value[EX seconds][PX milliseconds][NX|XX]，它也是原子性的。

SET key value [EX seconds] [PX milliseconds] [NX|XX]

• NX：表示 key 不存在的時(shí)候，才能 set 成功，即保證只有第一個(gè)客戶(hù)端請(qǐng)求才能獲得鎖，而其他客戶(hù)端請(qǐng)求只能等待鎖釋放后，才能獲取
• EX seconds :設(shè)定 key 的過(guò)期時(shí)間，默認(rèn)單位時(shí)間為秒
• PX milliseconds: 設(shè)定 key 的過(guò)期時(shí)間，默認(rèn)單位時(shí)間為毫秒
• XX: 僅當(dāng) key 存在時(shí)設(shè)置值

在 Go 語(yǔ)言里面，關(guān)鍵代碼如下所示：

func getLock() {    
   methodName := "getLock"    
   val, err := client.Do("set", methodName, "lock_value", "nx", "ex", 100) 
   if err != nil {        
       zaplog.Errorf("%s set redis lock failed, %s", methodName, err)
       return
  }    
   if val == nil { 
       zaplog.Errorf("%s get redis lock failed", methodName)        
       return 
  }
   ... // 執(zhí)行臨界區(qū)代碼，訪問(wèn)公共資源
   client.Del(lock.key()).Err() // 刪除key，釋放鎖
}

2）鎖提前釋放

上述方案解決了加鎖過(guò)期的原子性問(wèn)題，不會(huì)產(chǎn)生死鎖，但還是可能存在鎖提前釋放的問(wèn)題。

如圖所示，假設(shè)我們?cè)O(shè)置鎖的過(guò)期時(shí)間為 5 秒，而業(yè)務(wù)執(zhí)行需要 10 秒。

圖片

在線程 1 執(zhí)行業(yè)務(wù)的過(guò)程中，它的鎖被過(guò)期釋放了，這時(shí)線程 2 是可以拿到鎖的，也開(kāi)始訪問(wèn)公共資源。

很明顯，這種情況下導(dǎo)致了公共資源沒(méi)有被嚴(yán)格串行訪問(wèn)，破壞了分布式鎖的互斥性。

這時(shí)，有愛(ài)動(dòng)腦瓜子的小伙伴可能認(rèn)為，既然加鎖時(shí)間太短，那我們把鎖的過(guò)期時(shí)間設(shè)置得長(zhǎng)一些不就可以了嗎？

其實(shí)不然，首先我們沒(méi)法提前準(zhǔn)確知道一個(gè)業(yè)務(wù)執(zhí)行的具體時(shí)間。其次，公共資源的訪問(wèn)時(shí)間大概率是動(dòng)態(tài)變化的，時(shí)間設(shè)置得過(guò)長(zhǎng)也不好。

Redisson框架

所以，我們不妨給加鎖線程一個(gè)自動(dòng)續(xù)期的功能，即每隔一段時(shí)間檢查鎖是否還存在，如果存在就延長(zhǎng)鎖的時(shí)間，防止鎖過(guò)期提前釋放。

這個(gè)功能需要用到守護(hù)線程，當(dāng)前已經(jīng)有開(kāi)源框架幫我們解決了，它就是——Redisson，它的實(shí)現(xiàn)原理如圖所示：

圖片

當(dāng)線程 1 加鎖成功后，就會(huì)啟動(dòng)一個(gè) Watch dog 看門(mén)狗，它是一個(gè)后臺(tái)線程，每隔 1 秒（可配置）檢查業(yè)務(wù)是否還持有鎖，以達(dá)到線程未主動(dòng)釋放鎖，自動(dòng)續(xù)期的效果。

3）鎖被其它線程誤刪

除了鎖提前釋放，我們可能還會(huì)遇到鎖被其它線程誤刪的問(wèn)題。

圖片

如圖所示，加鎖線程 1 執(zhí)行完業(yè)務(wù)后，去釋放鎖。但線程 1 自己的鎖已經(jīng)釋放了，此時(shí)分布式鎖是由線程 2 持有的，就會(huì)誤刪線程 2 的鎖，但線程 2 的業(yè)務(wù)可能還沒(méi)執(zhí)行完畢，導(dǎo)致異常產(chǎn)生。

唯一 Value 值

要想解決鎖被誤刪的問(wèn)題，我們需要給每個(gè)線程的鎖加一個(gè)唯一標(biāo)識(shí)。

比如，在加鎖時(shí)將 Value 設(shè)置為線程對(duì)應(yīng)服務(wù)器的 IP。對(duì)應(yīng)的 Go 語(yǔ)言關(guān)鍵代碼如下：

const (  
   // HostIP，當(dāng)前服務(wù)器的IP  
   HostIP = getLocalIP()
)

func getLock() {    
   methodName := "getLock"    
   val, err := client.Do("set", methodName, HostIP, "nx", "ex", 100) 
   if err != nil {        
       zaplog.Errorf("%s redis error, %s", methodName, err)
       return
  }    
   if val == nil { 
       zaplog.Errorf("%s get redis lock error", methodName)        
       return 
  }
   ... // 執(zhí)行臨界區(qū)代碼，訪問(wèn)公共資源
   if client.Get(methodName) == HostIP {
       // 判斷為當(dāng)前服務(wù)器線程加的鎖，才可以刪除
       client.Del(lock.key()).Err()
  }
}

這樣，在刪除鎖的時(shí)候判斷一下 Value 是否為當(dāng)前實(shí)例的 IP，就可以避免誤刪除其它線程鎖的問(wèn)題了。

為了保證嚴(yán)格的原子性，可以用 Lua 腳本代替以上代碼，如下所示：

if redis.call('get',KEYS[1]) == ARGV[1] then
  return redis.call('del',KEYS[1])
else
  return 0
end;

4）Redlock高可用鎖

前面幾種方案都是基于單機(jī)版考慮，而實(shí)際業(yè)務(wù)中 Redis 一般都是集群部署的，所以我們接下來(lái)討論一下 Redis 分布式鎖的高可用問(wèn)題。

試想一下，如果線程 1 在 Redis 的 master 主節(jié)點(diǎn)上拿到了鎖，但是還沒(méi)同步到 slave 從節(jié)點(diǎn)。

這時(shí)，如果主節(jié)點(diǎn)發(fā)生故障，從節(jié)點(diǎn)升級(jí)為主節(jié)點(diǎn)，其它線程就可以重新獲取這個(gè)鎖，此時(shí)可能有多個(gè)線程拿到同一個(gè)鎖。即，分布式鎖的互斥性遭到了破壞。

為了解決這個(gè)問(wèn)題，Redis 的作者提出了專(zhuān)門(mén)支持分布式鎖的算法：Redis Distributed Lock，簡(jiǎn)稱(chēng) Redlock，其核心思想類(lèi)似于注冊(cè)中心的選舉機(jī)制。

Redis 集群內(nèi)部署多個(gè) master 主節(jié)點(diǎn)，它們相互獨(dú)立，即每個(gè)主節(jié)點(diǎn)之間不存在數(shù)據(jù)同步。

且節(jié)點(diǎn)數(shù)為單數(shù)個(gè)，每次當(dāng)客戶(hù)端搶鎖時(shí)，需要從這幾個(gè) master 節(jié)點(diǎn)去申請(qǐng)鎖，當(dāng)從一半以上的節(jié)點(diǎn)上獲取成功時(shí)，鎖才算獲取成功。

優(yōu)缺點(diǎn)和常用實(shí)現(xiàn)方式

以上是業(yè)界常用的三種分布式鎖實(shí)現(xiàn)方式，它們各自的優(yōu)缺點(diǎn)如下：

• 基于數(shù)據(jù)庫(kù)的分布式鎖：可靠性高，但性能較差，不適合高并發(fā)場(chǎng)景。
• 基于ZooKeeper的分布式鎖：提供良好的一致性和可用性，適合復(fù)雜的分布式場(chǎng)景，但部署和維護(hù)復(fù)雜，且性能比不上緩存的方式。
• 基于緩存的分布式鎖：性能較高，適合大部分場(chǎng)景，但需要處理緩存的高可用性。

其中，業(yè)界常用的分布式鎖實(shí)現(xiàn)方式通常是基于緩存的方式，如使用 Redis 實(shí)現(xiàn)分布式鎖。這是因?yàn)?Redis 性能優(yōu)秀，而且可以滿足大多數(shù)應(yīng)用場(chǎng)景的需求。

小結(jié)

盡管分布式世界曲折離奇，但有了分布式鎖，我們就像是看電影的觀眾，可以有條不紊地入場(chǎng)，分布式系統(tǒng)里的資源就像膠片一樣，等待著我們一張一張地觀賞。

這就是分布式的魅力！它或許令人又愛(ài)又恨，但正是科技世界的多樣復(fù)雜性，才讓我們的技術(shù)之旅變得更加精彩。