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

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

分布式鎖

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

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

• 數據庫
• Redis
• ZooKeeper

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

基于數據庫的分布式鎖實現(xiàn)

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

基于 for update 子句的悲觀鎖

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

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

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

基于唯一索引約束的分布式鎖實現(xiàn)

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

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

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

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='基于唯一索引約束的鎖';

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

基于 CAS 的樂觀鎖

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

在數據庫中，我們同樣也可以借用這種思想實現(xiàn) CAS 操作實現(xiàn)分布式樂觀鎖。同樣地，首先創(chuàng)建如下_lock表，這個表相比上一節(jié)多了一個 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='樂觀鎖實現(xiàn)';

樂觀鎖的執(zhí)行邏輯如下所示：

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);

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

總結

今天我們主要介紹了基于數據庫三種特性的分布式鎖實現(xiàn)，分別是基于 for update 子句的悲觀鎖、基于唯一索引約束的分布式鎖和基于 CAS 的樂觀鎖?；跀祿斓姆植际芥i方案的主要優(yōu)點是簡單可靠，不需要引入額外的依賴（大部分業(yè)務系統(tǒng)通常都會使用數據庫），同時，缺點也比較明顯，就是并發(fā)性能較差。因此，基于數據庫的分布式鎖方案比較適合并發(fā)較小的業(yè)務場景。