今天我想和你聊聊分布式鎖的使用場景和常見實現。熟悉多線程編程的同學對鎖的概念一定不會陌生。計算機操作系統中，為了解決多線程并發場景下的資源占用問題，引入了鎖的概念。通過鎖，我們可以保證一個資源在同一時刻只能被一個線程訪問。主流的編程語言都會在自己的標準庫中提供完備的鎖實現，這些實現已經能夠很好地解決我們在單進程應用中遇到的并發問題。

但是，隨著業務高速發展，業務系統會快速迭代拆分成多個子服務，同時，為了應對逐漸增加的流量，同一個子服務也會包含多個分立的實例，部署在不同的服務器上。整個系統逐步向微服務演進，此時，在單進程中已經被解決的并發問題又重新浮現出來，而分布式鎖就是解決這些問題的有效方案。

分布式鎖

分布式鎖可以協同那些部署在不同服務器上的進程對同一個資源的使用，實現同一個時刻只有一個線程可以訪問該資源。常見的分布式鎖的實現通常會選擇一個存儲系統作為全局狀態存儲，依賴這個存儲系統提供的對存儲對象原子化的排他性操作，來實現分布式鎖的全局排他性。

同時，通常我們也會將鎖的狀態、過期時間、持有者等信息保存在這個全局狀態存儲中，以實現更為豐富的鎖特性。常見的可以用來作為分布式鎖的全局狀態存儲的系統包括：

• 數據庫
• Redis
• ZooKeeper

關于 ZooKeeper 和 Reids 的分布鎖實現，我們將會放到下次講解。今天這節課，我們先來學習一下基于數據庫的分布鎖實現。

基于數據庫的分布式鎖實現

數據庫本身是一個強一致性的系統，有很多特性可以用來實現分布式鎖，如唯一索引約束、for update 子句等。

基于 for update 子句的悲觀鎖

這種鎖是for update子句可以利用 MySQL InnoDB 提供的排他鎖。在執行事務操作時，對于包含 for update 子句的 SQL 語句，MySQL 會對查詢結果集中的每一行記錄都設置一個排他鎖，其他線程在更新或刪除這些記錄時都會被阻塞。

基于這個機制，我們也可以很容易地實現分布式鎖的需求，在獲取鎖的時候開啟事務，成功獲取到鎖即可以執行業務邏輯，在業務邏輯結束后，完成事務即可以釋放鎖。

本實現方式簡單易用，但同樣不支持可重入，同時，本實現是阻塞的，鎖占用期間會一直占用數據庫連接，在高并發下容易出現耗盡連接池的情況，影響系統的穩定性。因此，在實際場景中很少使用這個方案。

基于唯一索引約束的分布式鎖實現

一個表如果存在唯一鍵索引，只有第一次插入操作會成功，其他插入操作都會報錯。

首先創建如下_lock表，其中resource_key即為唯一鍵，表示一個需要搶占的資源。應用在獲取鎖的時候，實際會往這張表里插入一條 resource_key 為該資源 key 的記錄，插入成功即為獲取了鎖，刪除這條記錄即為解鎖。如果插入失敗，則需要重復執行插入操作，直到插入成功或者超過指定的超時時間，拋出異常。

同時，為了避免操作失敗等原因導致鎖記錄沒有正確被刪除，通常需要額外增加一個定時清理任務來清理過期的鎖記錄，以避免出現死鎖，這一過程的實現代碼如下：

CREATE TABLE`_lock` (
    `id`BIGINTNOTNULL AUTO_INCREMENT,
    `resource_key`varchar(64) NOTNULLCOMMENT'鎖定的資源 Key，表示一個需要占用的資源'
    PRIMARY KEY (`id`),
    UNIQUEKEY`uk_resource_key` (`resource_key`)  USING BTREE
) ENGINE=InnoDBDEFAULTCHARSET=utf8mb4 COMMENT='基于唯一索引約束的鎖';

基于唯一索引約束的分布式鎖實現原理非常簡單，使用起來也十分簡便，但是它的缺點也十分明顯。首先，這個鎖實現不支持可重入，為了實現可重入操作，還需要進一步擴展上述表的字段，將鎖持有者的主機、線程等信息記錄到里面，在獲取鎖的時候，先判斷鎖記錄中的相關信息是否和當前主機、線程信息一致，如果一致就直接認為已經獲取了鎖。其次，在并發下，這種插入操作會造成大量死鎖，影響數據庫的穩定。

基于 CAS 的樂觀鎖

CAS（Compare And Swap) 是現代 CPU 支持的一個指令級的操作，即在更新數據前先比較該數據當前值是否等于期望值，如果相等，則將其設置為更新的值，否則就不設置。該指令通常用來實現樂觀鎖，Java 的 Java.util.concurrent.atomic 包提供了大量支持 CAS 操作的原子變量。

在數據庫中，我們同樣也可以借用這種思想實現 CAS 操作實現分布式樂觀鎖。同樣地，首先創建如下_lock表，這個表相比上一節多了一個 version 字段，這個字段就是在 CAS 操作中用于比較交換的字段。

CREATE TABLE`_lock` (
`id`int(4) NOTNULL AUTO_INCREMENT COMMENT'主鍵',
`resource_key`varchar(64) NOTNULLDEFAULT''COMMENT'鎖定的資源 Key，表示一個需要占用的資源',
`version`int(4) NOTNULLDEFAULT''COMMENT'版本號'
  PRIMARY KEY (`id`),
UNIQUEKEY`uk_resource_key` (`resource_key `) USING BTREE
) ENGINE=InnoDBDEFAULTCHARSET=utf8 COMMENT='樂觀鎖實現';

樂觀鎖的執行邏輯如下所示：

do {
    val old_version = (select version from _lock where resource_key = '{resource_key_1}');
    // 通過 CAS 更新 version, 一次事務僅又一個進程可以成功
    bool success = (update _lock set version = '{new_version}' where resource_key = '{resource_key_1}' and version = '{old_version}'")
    if (success) {
        // 獲取鎖成功，直接返回
        return;
    }
    // 獲取失敗，重試
} while(true);

樂觀鎖認為數據的更新在大多數情況下是不會產生沖突的，所以只在更新操作提交時才進行沖突檢測。樂觀鎖通常比較適合多讀的場景，可以增加系統的吞吐量。

總結

今天我們主要介紹了基于數據庫三種特性的分布式鎖實現，分別是基于 for update 子句的悲觀鎖、基于唯一索引約束的分布式鎖和基于 CAS 的樂觀鎖。基于數據庫的分布式鎖方案的主要優點是簡單可靠，不需要引入額外的依賴（大部分業務系統通常都會使用數據庫），同時，缺點也比較明顯，就是并發性能較差。因此，基于數據庫的分布式鎖方案比較適合并發較小的業務場景。