架構與思維：分布式鎖方案分析

1 介紹

前面的文章我們介紹了分布式系統和它的CAP原理：一致性（Consistency）、可用性（Availability）和分區容錯性（Partition tolerance）。參考這篇《分布式事務》

我們知道，一個分布式系統無法同時滿足三個特性，所以在設計系統之初，就有一個特性要被妥協和犧牲，因為分區容錯性的不可或缺性，一般我們的選擇是AP或者CP，這就要求我們要么舍棄強一致性，要么舍棄高可用。

為了達到數據的一致性，或者說至少達到數據的最終一致性，我們需要一些額外的方法來保證，比如分布式事務，分布式鎖等等。

2 關於分布式鎖

在單體系統中，我們經常會遇到很多高並發的場景，比如熱點數據、熱點緩存，短時間會有大量的請求進行訪問，當多個線程同時訪問共享資源的時候，就可能產生數據不一致的情況。

為了保證操作的順序性、原子性，所以我們需要輔助，比如在線程間中加鎖，當某個線程得到資源的時候，就對當前的資源進行加鎖，等完成操作之后，進行釋放，其他線程就可以繼續使用了。

Java在多線程實現中，專門提供了一些鎖機制來保障線程的互斥同步（synchronized/ReentrantLock）等。

synchronized(object:this){
   // todo 業務邏輯
}
====================================
Lock lock = new ReentrantLock(); 
Condition condition = lock.newCondition(); 
lock.lock(); 
try { 
 while(這邊是條件表達式) { 
   condition.wait(); 
   // todo 業務邏輯 
  } 
 } finally { 
    lock.unlock(); 
}

這種方式對於同一個module里面的操作是沒什么問題，但是在分布式系統中，就沒什么用了，比如很典型的支付場景、跨行轉賬場景，均屬於多系統之間的資源操作。

所以，為了解決這個問題，我們就必須引入分布式鎖，來保障多個不同系統對共享資源進行互斥訪問。

分布式鎖需要解決的問題一般包含如下：

1、排他性：分布式部署的應用集群中，同一個方法在同一時間只能被一台機器上的一個線程執行。

2、避免死鎖：鎖在執行一段有限的時間之后，會被釋放（正常釋放或異常導致自動釋放），並且可以被重入，即當前線程可重復獲取。

3、高可用/高性能：獲取鎖和釋放鎖具備高可用；獲取和釋放鎖的性能優良。

3 分布式鎖的實現方案

分布式鎖的實現，比較常見的方案有3種：

1、基於數據庫實現分布式鎖

2、基於緩存（Redis或其他類型緩存）實現分布式鎖

3、基於Zookeeper實現分布式鎖

這三種方案，從實現的復雜度上來看，從1到3難度依次遞增。而且並不是每種解決方案都是完美的，它們都有各自的特性，還是需要根據實際的場景進行抉擇的。

3.1  基於數據庫實現

3.1.1 樂觀鎖的實現方式

樂觀鎖機制其實就是在數據庫表中引入一個版本號（version）字段來實現。如下，再表上添加了一個version字段，並且設置為bigint類型：

CREATE TABLE `t_pay` (
`id` BIGINT ( 20 ) NOT NULL AUTO_INCREMENT,
`pay_id` BIGINT (8) NOT NULL COMMENT '支付id',
`pay_count` BIG (8) DEFAULT 0 not NULL COMMENT '支付次數',
`balance` DECIMAL (6,2) DEFAULT 0 not NULL COMMENT '總額度',
`version` BIGINT (10) DEFAULT 0  NOT NULL COMMENT '版本號',
PRIMARY KEY ( `id` )
) ENGINE = INNODB AUTO_INCREMENT = 137587 DEFAULT CHARSET = utf8 COMMENT = '用戶支付信息表'; 

在每次進行數據庫表之前先查詢一下當前記錄信息，然后執行更新語句並且讓指定字段進行自增，即 version = version+1 (因為MySQL同一張表只支持一個自增鍵，這邊已經被id用了)。

修改完將新的數據與新的version更新到數據表中，更新的同時檢查目前數據庫里version值是不是之前的那個version，如果是，則正常更新。

如果不是，則更新失敗，說明在這個執行間隙有其它的進程去更新過數據了，這時候如果強行更新進去，支付次數和總額度就不對了。操作如下：

-- 先查詢數據信息
select pay_id,pay_count,balance,version from t_pay where id= #{id}
-- 判斷當前表中的version 是否與剛才查出的version一致，是的話正常更新
update t_pay set pay_count=paycount + 1, balance = balance + '具體消費額度' ,version = version+1 where id=#{id} and version= #{version};

根據返回修改記錄條數來判斷當前更新是否生效，如果改動的是0條數據，說明version發生了變更，導致改動無效，這時候可以根據自己業務邏輯來判斷是否回滾事務。

下面圖例分析一下：

 

舉例如圖，你跟你老婆用同一個賬戶在支付，你支付燃氣費，你老婆夠買手表，如果沒有鎖機制，在並發的情況下，可能會出現同時被扣25和8000，導致最終余額的不正確。

但是如果使用樂觀鎖機制，當兩個請求同時到達的時候，需要獲取到賬號信息包括版本號信息，不管是A操作（支付燃氣費）還是B操作（購買手表），都會將版本號加1，即version=2，

那么另外一個操作執行的時候，發現當前版本號變成了2，不再是之前讀取的 1，則更新失敗。

通過上面這個例子可以看出來，使用「樂觀鎖」機制，必須得滿足：

a）鎖服務要有遞增的版本號 version

b）每次更新數據的時候都必須先判斷版本號對不對，然后再寫入新的版本號

3.1.2 悲觀鎖的實現方式

悲觀鎖也叫作排它鎖，在MySQL中是基於 for update  語法來實現加鎖的，下面用偽代碼來演示，例如：

// 鎖定的方法
public boolean lock(){
    connection.setAutoCommit(false)
    while(true){
        result = 
        select * from t_pay where 
        id = 100 for update;
        if(result){
         // 結果不為空，
         // 則說明獲取到了鎖
            return true;
        }
        // 沒有獲取到鎖，繼續獲取
        sleep(1000);
    }
    return false;
}

// 釋放鎖
connection.commit(); 

上面的示例中，user表中，id是主鍵，通過 for update 操作，數據庫在查詢的時候就會給這條記錄加上排它鎖。（需要注意的是，在InnoDB中只有檢索字段加了索引的，才會是行級鎖，否者是表級鎖，所以這個id字段要加索引），

當這條記錄加上排它鎖之后，其它線程是無法操作這條記錄的。

那么，這樣的話，我們就可以認為獲得了排它鎖的這個線程是擁有了分布式鎖，然后就可以執行我們想要做的業務邏輯，當邏輯完成之后，再調用上述釋放鎖的語句即可。 

3.1.3 數據庫鎖的優缺點

直接使用數據庫，容易理解、操作簡單。

但是會有各種各樣的問題，在解決問題的過程中會使整個方案變得越來越復雜。操作數據庫需要一定的開銷，性能問題需要考慮，特別是高並發場景下。

使用數據庫的行級鎖並不一定靠譜，尤其是當我們的鎖表並不大的時候。 

3.2  基於Redis實現

3.2.1 基於緩存實現分布式鎖

相比較於基於數據庫實現分布式鎖的方案來說，基於緩存來實現在性能方面會表現的更好一點。類似Redis可以多集群部署的，解決單點問題。

基於Redis實現的鎖機制，主要是依賴redis自身的原子操作，例如：

# 判斷是否存在，不存在設值，並提供自動過期時間
SET key value NX PX millisecond

# 刪除某個key
DEL key [key …] 

NX：只在在鍵不存在時，才對鍵進行設置操作，SET key value NX 效果等同於 SETNX key value
PX millisecond：設置鍵的過期時間為millisecond毫秒，當超過這個時間后，設置的鍵會自動失效

如果需要把上面的支付業務實現，則需要改寫如下：

# 設置賬戶Id為17124的賬號的值為1，如果不存在的情況下，並設置過期時間為500ms
SET pay_id_17124 1 NX PX 500

# 進行刪除
DEL pay_id_17124 

上述代碼示例是指，

當redis中不存在pay_key這個鍵的時候，才會去設置一個pay_key鍵，鍵的值為 1，且這個鍵的存活時間為500ms。

當某個進程設置成功之后，就可以去執行業務邏輯了，等業務邏輯執行完畢之后，再去進行解鎖。而解鎖之前或者自動過期之前，其他進程是進不來的。

實現鎖機制的原理是：這個命令是只有在某個key不存在的時候，才會執行成功。那么當多個進程同時並發的去設置同一個key的時候，就永遠只會有一個進程成功。

解鎖很簡單，只需要刪除這個key就可以了。

另外，針對redis集群模式的分布式鎖，可以采用redis的Redlock機制。

需要注意的是，如何設置恰當的超時時間，如果設置的失效時間太短，方法沒等執行完，鎖就自動釋放了，那么就會產生並發問題。如果設置的時間太長，其他獲取鎖的線程就要多等一段時間。這個問題使用數據庫實現分布式鎖同樣存在。

總結：可以使用緩存來代替數據庫來實現分布式鎖，會提供更好的性能，同時，很多緩存服務都是集群部署的，可以避免單點問題。

並且很多緩存服務都提供了可以用來實現分布式鎖的方法，比如redis的setnx方法。並且，緩存服務也都提供了對數據的過期自動刪除的支持，可以直接設置超時時間來控制鎖的釋放。

3.2.2 緩存實現分布式鎖的優缺點 

優點是性能好，實現起來較為方便。缺點是通過超時時間來控制鎖的失效時間並不是十分的靠譜。

3.3 基於Zookeeper實現

3.3.1 實現過程

基於zookeeper臨時有序節點可以實現分布式鎖。

其原理如下：

1、每個請求的客戶端，都去Zookeeper上的某個指定節點的目錄下（比如是對某個對象的操作），去生成一個唯一的臨時有序節點。

2、然后判斷自己是否是這些有序節點中序號最小的一個，如果是，則算是獲取了鎖。

3、如果不是最小序號，則說明沒有獲取到鎖，那么就需要在序列中找到比自己小的那個節點，對其注冊事件監聽（調用exits()方法確認節點在不在）。比如下面圖中，client-3 生成 node-3，並監聽node-2。

4、當監聽到這個節點被刪除了，那就再去判斷一次自己當初創建的節點是否變成了序列中最小的。如果是，則獲取鎖，如果不是，則重復上述步驟。

//創建子節點
private String createSaNode() throws KeeperException, InterruptedException {
// 如果根節點不存在，則創建根節點
Stat stat = zk.exists(ZNODE, false);
if (stat == null) {
zk.create(ZNODE, new byte[0], ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);
}

String hostName = System.getenv("HOSTNAME");
// 創建EPHEMERAL_SEQUENTIAL類型節點
String saPath = zk.create(ZNODE + "/" + SA_NODE_PREFIX,
hostName.getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE,
CreateMode.EPHEMERAL_SEQUENTIAL);
return saPath;
}

完整的實現方案可以參考：https://blog.csdn.net/liyiming2017/article/details/85063868

根據上訴的步驟，Zookeeper實際解決了如下問題：

• 鎖無法釋放？使用Zookeeper可以有效的解決鎖無法釋放的問題，因為在創建鎖的時候，客戶端會在ZK中創建一個臨時節點，一旦客戶端獲取到鎖之后突然掛掉（Session連接斷開），那么這個臨時節點就會自動刪除掉。其他客戶端就可以再次獲得鎖。

• 非阻塞鎖？使用Zookeeper可以實現阻塞的鎖，客戶端可以通過在ZK中創建順序節點，並且在節點上綁定監聽器，一旦節點有變化，Zookeeper會通知客戶端，客戶端可以檢查自己創建的節點是不是當前所有節點中序號最小的，如果是，那么自己就獲取到鎖，便可以執行業務邏輯了。

• 不可重入？使用Zookeeper也可以有效的解決不可重入的問題，客戶端在創建節點的時候，把當前客戶端的主機信息和線程信息直接寫入到節點中，下次想要獲取鎖的時候和當前最小的節點中的數據比對一下就可以了。如果和自己的信息一樣，那么自己直接獲取到鎖，如果不一樣就再創建一個臨時的順序節點，參與排隊。

• 單點問題？使用Zookeeper可以有效的解決單點問題，ZK是集群部署的，只要集群中有半數以上的機器存活，就可以對外提供服務。

下面圖例說明：

 

Locker Object 是對需要競爭的資源進行持久的節點，下面的node-1到node-n 就是上面說的有序子節點，由不同進程的client去創建。

當進來一個客戶端需要去競爭資源的時候，就跑到持久化節點下去按順序創建一個直接點，然后看一下是不是最小的一個。

如果是最小的就獲取到鎖，可以繼續后面的資源操作了。如果不是則監聽比自己序號小的節點，比如client-3 訂閱的是 node-2。

如果node-2被刪除，自己被喚醒，再次判斷自己是不是序列中最小的，如果是，則獲取鎖。

3.3.2 zk實現分布式鎖的優缺點 

優點：有效的解決單點問題，不可重入問題，非阻塞問題以及鎖無法釋放的問題。實現起來較為簡單。

缺點：性能上不如使用緩存實現分布式鎖。 需要對ZK的原理有所了解。

3.4 三種方案的對比總結

上面幾種方式，並不是都能做到十全十美，就像CAP一樣，在復雜性、可靠性、性能 三方面無法同時滿足一樣。所以，更多的是根據不同的應用場景選擇最合適的方案。

 

特性	實現復雜度角度	性能角度	可靠性角度
數據庫	高	低	低
緩存	中	高	中
Zookeeper	低	中	高