公司交給了萌新小猿一個光榮而艱巨的項目，該項目需要使用分布式鎖，這可難到了小猿。

[[321687]]

圖片來自 Pexels

只是聽說過分布式鎖很牛掰，其他就一概不知了，唉，不懂就問唄，遂向老板請教。

老板：我們每天不都在經歷分布式鎖嗎，我來給你回憶回憶。

小猿：好勒，瓜子板凳已備好。

本文結構：

• 為什么要使用分布式鎖
• 分布式鎖有哪些特點
• 分布式鎖流行算法及其優缺點
• 總結

為什么要使用分布式鎖

這個問題應該拆分成以下 2 個問題回答。

①為什么使用鎖

保證在同一時刻共享資源只能被一個客戶端訪問;根據鎖用途分為以下兩種：

• 共享資源只允許一個客戶端操作
• 共享資源允許多個客戶端操作

僅允許一個客戶端訪問：共享資源的操作不具備冪等性。常見于數據的修改、刪除操作。

在上面的例子中：

允許多個客戶端操作：主要應用場景是共享資源的操作具有冪等性;如數據的查詢。

既然都具有冪等性了，為什么還需要分布式鎖呢，通常是為了效率或性能，避免重復操作(尤其是消耗資源的操作)。

例如我們常見的緩存方案：

在上面的例子中：

由于此處的資源是冪等的，通常會將這類資源做緩存，這就是常見的鎖+緩存架構。

常適用于獲取較為消耗資源(時間、內存、CPU 等)的冪等資源，如：

• 查詢用戶信息
• 查詢歷史訂單

當然，如果資源僅在一段時間范圍內具有冪等性，這時候，架構就應該升級了：

鎖+緩存+緩存失效/失效重新獲取/緩存定時更新。

②鎖為什么需要分布式的?

還是以上面的緩存方案為例，此處略作變化：

在上面的例子中：

分布式鎖有哪些特點?

①互斥性

在任意時刻，僅允許有一個客戶端獲得鎖。

PS：如果多個客戶端都能同時獲得鎖，那鎖就沒意義了，共享資源的安全性也就無法保證了。

老板：當我在會議室接待客戶 A 時，其他客戶只有等待，你需要等到我空閑了才能把其他人帶到我辦公室。

小猿：明白。

接待客戶(非冪等共享資源);等到老板空閑(獲取鎖)。

②可重入性

客戶端 A 獲得了鎖，只要鎖沒有過期，客戶端 A 可以繼續獲得該鎖。鎖在我這里，我還要繼續使用，其他人不準搶。

這種特性可以很好的支持【鎖續約】功能。例如：客戶端 A 獲取鎖，鎖釋放時間為 10S，即將到達 10S 時，客戶端 A 未完成任務，需要再申請 5S。若鎖沒有可重入性，客戶端 A 將無法續約，導致鎖可能被其他客戶端搶走。

小猿：受教了，老板 3 分鐘后你還有一場面試。

老板：小猿啊，難得你這么好學，我很欣慰，我們的交流時間延10分鐘吧，其他會議延后。

③高性能

獲取鎖的效率應該足夠高;總不能讓業務阻塞在獲取鎖上面吧?

小猿：好的，我已在釘釘申請將會議延長 10 分鐘了。

老板：嗯，我已經接受會議邀請了;

小猿：老板你真高效。

④高可用

分布式、微服務環境下，必須保證服務的高可用，否則輕則影響其他業務模塊，重則引發服務雪崩。

老板：我手機 24 小時開機，有會議時聯系不上我也可以聯系我秘書。

⑤支持阻塞和非阻塞式鎖

獲取鎖失敗，是直接返回失敗，還是一直阻塞知道獲取成功?不同的業務場景有不同的答案。

例如：

⑥解鎖權限

客戶端僅能釋放(解鎖)自己加的鎖。常見的解決方案是，給鎖加隨機數(或 ThreadID)。

老板：小猿啊，給你講了這么多，都明白了嗎?

籠子里的鸚鵡：明白啦，明白啦。

老板：閉嘴，我問的是小猿，只有小猿自己有資格回答。

⑦避免死鎖

加鎖方異常終止無法主動釋放鎖;常規做法是 加鎖時設置超時時間，如果未主動釋放鎖，則利用 Redis 的自動過期被動釋放鎖。

秘書破門而入：老板，你們 10 分鐘的會議已經到點了，隔壁的李總已經等不及了。

老板：一不留神就忘記時間了，我得去見李總了。

小猿：老板，我們還沒聊完呢...

⑧異常處理

常見的異常情況有 Redis 宕機、時鐘跳躍、網絡故障等。

小猿：不管出現哪種情況，我獲取鎖都會失敗啊，這可怎么辦呢?

PS：這就復雜了，需要根據具體的業務場景分析。對于必須同步處理的業務，則必須失敗告警，對于允許延遲處理的業務可以考慮記錄失敗信息待其他系統處理。

分布式鎖流行算法

基本方案 SETNX

基于 Redis 的 SETNX 指令完成鎖的獲取。

①獲取鎖 SET lock：resource_name random_value NX PX 30000

lock：resource_name：資源名字，加鎖對象的唯一標記。

random_value：通常存儲加鎖方的唯一標記，如“UUID+ThreadID”。

NX：Key 不存在才設置，即鎖未被其他人加鎖才能加鎖。

PX：鎖超時時間。

當然，此種加鎖方式是不支持“鎖重入性”的。

②釋放鎖(LUA 腳本)

checkValueThenDelete：檢查解鎖方是否是加鎖方，是則允許解鎖，否則不允許解鎖。

偽代碼是：

public class RedisTool { 
    // 釋放鎖成功標記 
    private static final Long RELEASE_LOCK_SUCCESS = 1L; 
 
    /** 
     * 釋放分布式鎖 
     * 
     * @param jedis     Redis客戶端 
     * @param lockKey   鎖標記 
     * @param lockValue 加鎖方標記 
     * @return 是否釋放成功 
     */ 
    public static boolean releaseDistributedLock(Jedis jedis, String lockKey, String lockValue) { 
        String script = "" + 
                "if redis.call('get', KEYS[1]) == ARGV[1] then" + 
                "    return redis.call('del', KEYS[1]) " + 
                "else" + 
                "    return 0 " + 
                "end"; 
        // Collections.singletonList()：用于只有一個元素的場景，減少內存分配 
        Object result = jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(lockValue)); 
        if (RELEASE_LOCK_SUCCESS.equals(result)) { 
            return true; 
        } 
        return false; 
    } 
} 

Redlock 算法

此算法由 Redis 作者 antirez 提出，作為一種分布式場景下的鎖實現方案。

Redlock 算法原理：【核心】大多數節點獲取鎖成功且鎖依舊有效。

Step 1：獲取當前時間(毫秒數)。

Step 2：按序想 N 個 Redis 節點獲取鎖。設置隨機字符串 random_value;設置鎖過期時間：

• Note 1：獲取鎖需設置超時時間(防止某個節點不可用)，且 timeout 應遠小于鎖有效時間(幾十毫秒級)。
• Note 2：某節點獲取鎖失敗后，立即向下一個節點獲取鎖(任何類型失敗，包含該節點上的鎖已被其他客戶端持有)。

Step 3：計算獲取鎖的總耗時 totalTime。

Step 4：獲取鎖成功。

獲取鎖成功：客戶端從大多數節點(>=N/2+1)成功獲取鎖，且 totalTime 不超過鎖的有效時間。

重新計算鎖有效時間：最初鎖有效時間減 3.1 計算的獲取鎖消耗的時間。

Step 5：獲取鎖失敗。

獲取失敗后應立即向【所有】客戶端發起釋放鎖(Lua 腳本)。

Step 6：釋放鎖。

業務完成后應立即向【所有】客戶端發起釋放鎖(Lua 腳本)。

Redlock 算法優點：

• 可用性高，大多數節點正常即可。
• 單 Redis 節點的分布式鎖在 failover 時鎖失效問題不復存在。

Redlock 算法問題點：

• Redis 節點崩潰將影響鎖安全性：節點崩潰前鎖未持久化，節點重啟后鎖將丟失;Redis 默認 AOF 持久化是每秒刷盤(fsync)一次，最壞情況將丟失 1 秒的數據。
• 需避免始終跳躍：管理員手動修改時鐘;使用[不會跳躍調整系統時鐘]的 ntpd(時鐘同步)程序，對時鐘修改通過多次微調實現。
• 客戶端阻塞導致鎖過期，導致共享資源不安全。
• 如果獲取鎖消耗時間較長，導致效時間很短，是否應該立即釋放鎖?多段才算短?

帶 fencing token 的實現

分布式系統專家 Martin Kleppmann 討論提出 RedLock 存在安全性問題。

神仙之戰：Martin Kleppmann 認為 Redis 作者 antirez 提出的 RedLock 算法有安全性問題，雙方在網絡上多輪探討交鋒。

Martin 指出 RedLock 算法的核心問題點如下：

• 鎖過期或者網絡延遲將導致鎖沖突：客戶端 A 進程 pause→鎖過期→客戶端 B 持有鎖→客戶端 A 恢復并向共享資源發起寫請求;網絡延遲也會產生類似效果。
• RedLock 安全性對系統時鐘有強依賴。

fencing token 算法原理：

• fencing token 是一個單調遞增的數字，當客戶端成功獲取鎖時隨同鎖一起返回給客戶端。
• 客戶端訪問共享資源時帶上 token。
• 共享資源服務檢查 token，拒絕延遲到來的請求。

fencing token 算法問題點：

• 需要改造共享資源服務。
• 如果資源服務也是分布式，如何保證 token 在多個資源服務節點遞增。
• 2 個 fencing token 到達資源服務的順序顛倒，服務檢查將異常。
• 【antirez】既然存在 fencing 機制保持資源互斥訪問，為什么還需要分布式鎖且要求強安全性呢。

其他分布式鎖

數據庫排它鎖：

• 獲取鎖(select for update ，悲觀鎖)。
• 處理業務邏輯。
• 釋放鎖(connection.commit())。

注意：InnoDB 引擎在加鎖的時候，只有通過索引進行檢索的時候才會使用行級鎖，否則會使用表級鎖。So 必須給 lock_name 加索引。

ZooKeeper 分布式鎖：

• 客戶端創建 znode 節點，創建成功則獲取鎖成功。
• 持有鎖的客戶端訪問共享資源完成后刪除 znode。
• znode 創建成 ephemeral(znode 特性)，保證創建 znode 的客戶端崩潰后，znode 會被自動刪除。
• 【問題】Zookeeper 基于客戶端與 Zookeeper 某臺服務器維護 Session，Session 依賴定期心跳(heartbeat)維持。

Zookeeper 長時間收不到客戶端心跳，就任務 Session 過期，這個 Session 所創建的所有 ephemeral 類型的 znode 節點都將被刪除。

Google 的 Chubby 分布式鎖：

• sequencer 機制(類似 fencing token)緩解延遲導致的問題。
• 鎖持有者可隨時請求一個 sequencer。
• 客戶端操作資源時將 sequencer 傳給資源服務器。
• 資源服務器檢查 sequencer 有效性：①調用 Chubby 的 API(CheckSequencer)檢查。②對比檢查客戶端、資源服務器當前觀察到的 sequencer(類似 fencing token)。③lock-delay：允許客戶端為持有鎖指定一個 lock-delay 延遲時間，Chubby 發現客戶端失去聯系時，在 lock-delay 時間內組織其他客戶端獲取鎖;

總結

我們該使用怎樣的分布式鎖算法?

• 技術都是為業務服務的，避免選擇“高大上”的炫技;
• 依托業務場景，盡可能選擇最簡單的做法;
• 最簡單的分布式鎖導致偶發性異常如何處理呢?建議增加額外的機制甚至人工介入保證業務準確性，通常這部分成本低于復雜的分布式鎖的開發、運維成本。

分布式鎖的另類玩法，“分而治之”經久不衰：

• 如果共享資源本身可以拆分，那就分開處理吧。
• 比如電商系統防止超賣，假設有 10000 個口罩將被秒殺，常規做法是一個鎖控制所有資源。另類玩法就是將 10000 個口罩交由 20 個鎖控制，整體性能瞬間提升幾十倍。

PS：此處超賣僅是舉例，真實場景下的秒殺超賣有更加復雜的場景，慎重。