一、背景

二、分布式鎖介紹

1、什么是分布式鎖

先了解一下什么是鎖，在單機系統(tǒng)中，多個線程同時改變一個變量時，需要對變量或者代碼塊做同步從而保證串行修改變量，該同步實質(zhì)上就是通過鎖來實現(xiàn)。為了實現(xiàn)多個線程在同一個時刻針對同一塊代碼串行執(zhí)行，就需要在某個地方做個標記，該標記必須每個線程都能看到，當標記不存在時可以設置該標記，其余后續(xù)線程發(fā)現(xiàn)已經(jīng)有標記了則等待擁有標記的線程結(jié)束同步代碼塊取消標記后再去嘗試設置標記，此標記可以理解為鎖。分布式鎖就是在多機系統(tǒng)下的該標記。

創(chuàng)新互聯(lián)主要從事網(wǎng)站建設、網(wǎng)站制作、網(wǎng)頁設計、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務。立足成都服務平遠,十載網(wǎng)站建設經(jīng)驗,價格優(yōu)惠、服務專業(yè),歡迎來電咨詢建站服務:13518219792

2、實現(xiàn)分布式鎖的主流方式

目前分布式鎖的實現(xiàn)方式有3種主流方法，即：

1）基于數(shù)據(jù)庫實現(xiàn)分布式鎖，此處的數(shù)據(jù)庫指的是MySQL關(guān)系型數(shù)據(jù)庫；

• 基于MySQL鎖表
• 數(shù)據(jù)庫版本號樂觀鎖

2）基于緩存實現(xiàn)分布式鎖，此處的緩存指的是Redis；

3）基于zookeeper/etcd實現(xiàn)分布式鎖。

具體的關(guān)于鎖的實現(xiàn)方式，已經(jīng)有太多的文章進行介紹，本文就不再贅述。

三、質(zhì)量保障

并發(fā)問題一旦涉及到錢，通常都會導致不同程度的資損，而且在我們的功能測試中是很難發(fā)現(xiàn)，因此對于并發(fā)的質(zhì)量保障顯得尤為的重要，可以抽象為3層來保障：事前、事中、事后三大步驟；事前保障通過Review 方式提前規(guī)避技術(shù)上的風險，事中保障驗證在技術(shù)實現(xiàn)過程中是否存在漏洞，事后保障校驗數(shù)據(jù)是否符合預期，對于有并發(fā)風險的項目上述三個步驟的保障缺一不可。

1、事前質(zhì)量保障

事前保障的階段發(fā)生在技術(shù)評審階段，在此階段，我們需要評估出當前業(yè)務場景下是否存在并發(fā)風險；如果存在，確定我們的技術(shù)選型。

1）評估并發(fā)風險

評估并發(fā)風險的關(guān)鍵點在于是否存在多個進程同時訪問共享資源，簡單來說是否存在多個進程在同一時間對同一個數(shù)據(jù)進行更新的操作；例如：電商中的庫存，多人同時購買同一個商品，也就是會存在同一時間對同一個商品的庫存進行更新，此處就存在并發(fā)風險。

2）技術(shù)選型

要做到正確的技術(shù)選型，我們就需要對上述3種方式實現(xiàn)的鎖的優(yōu)缺點以及應用場景需要進行了解。

MySQL數(shù)據(jù)庫表的樂觀鎖適用于讀多寫少的場景且共享資源為數(shù)據(jù)庫的單行數(shù)據(jù)；MySQL表鎖實現(xiàn)的鎖一般都不推薦使用；ZooKeeper分布式鎖雖然適用于大部分分布式場景，但是由于其實現(xiàn)復雜度相對較高以及需要額外引入中間件，在大部分業(yè)務場景中的應用比較少，而基于Redis的緩存分布式鎖應用較為廣泛；但是具體業(yè)務實現(xiàn)采用哪種類型的分布式鎖，還是需要基于當前的業(yè)務特性來進行決定；

在技術(shù)評審階段，一方面我們要評估出是否存在并發(fā)風險，另外一方面，我們需要識別開發(fā)同學在技術(shù)的實現(xiàn)上可能存在的漏洞，針對分布式鎖的實現(xiàn)漏洞可參考下文的CodeReview的關(guān)注點。

2、事中保障

1）CodeReview

① Redis緩存分布式鎖

Redis通?？梢允褂胹etnx(key,value)函數(shù)來實現(xiàn)分布式鎖。key和value就是基于緩存的分布式鎖的兩個屬性，其中key表示鎖id。setnx函數(shù)返回1表示獲得鎖，返回0表示其他服務器已經(jīng)獲得了鎖；

Redis緩存分布式鎖CodeReview注意點：

a. Redis Key

• 全面梳理業(yè)務場景，對于同一共同資源，key要保持一致；
• key是識別共享資源的唯一鍵，key的設計既需要能夠鎖住當前共享資源又不能影響到其他資源。

例如：商品庫存，我們的key應該是具體到某個商品，而不是所有商品，鎖住A商品，不會影響B(tài)商品。

b. 鎖釋放

• 鎖一定需明確釋放，try/finally 結(jié)構(gòu)加鎖解鎖，finally內(nèi)釋放鎖：
• 鎖只能被加鎖的對象釋放，此處是經(jīng)常出問題的點，如下圖所示，A加鎖被B釋放鎖，導致鎖失效，鎖被C搶占到。

針對上述問題，釋放鎖時需要先讀取當前key的value,再和傳入的value進行比較；上述是兩個步驟一定要保證原子性,如果原生Redis可采用lua腳本保證原子性；如果tair，可采取TairString的cad方法；value必須是一個唯一值，唯一標記是當前對象加的鎖。

c. 鎖超時

• 一定要設置key的超時時間；例如:客戶端A 搶到鎖后，系統(tǒng)突然異常，A就無法釋放鎖，變成死鎖；設置超時時間就是為了防止此種情況發(fā)生，在時間到期后，自動刪除key，間接釋放鎖：
• 超時時間的設置一般來講大于服務的最大執(zhí)行時間即可，但是服務最大的執(zhí)行時間會受很多因素影響，是不可控的；例如：A服務一般執(zhí)行時間是30ms，設置的鎖超時時間為100ms，受網(wǎng)絡影響服務執(zhí)行時間變成了200ms，在100ms的時候鎖就會被釋放了；在大部分場景下，開發(fā)不會處理此種情況，此種極端情況是否需要處理，需要進行協(xié)商；處理方式如下2種：

可以再開啟一個線程，為當前超時時間續(xù)時，但增加了系統(tǒng)的復雜度；

將過期時間設置非常長，一定能保證邏輯在鎖釋放之前能夠執(zhí)行完成；此方案簡單但是有缺陷，當遇到系統(tǒng)突發(fā)異常時，鎖無法被釋放，只能等待redis key超時，而超時時間又設置的較長，因此在當前時間內(nèi)誰都無法獲取到鎖，阻斷業(yè)務執(zhí)行，很有可能造成故障。

d. 鎖粒度

如果針對某個共享資源的寫是基于另外一個共享資源的值計算而來，那么鎖的范圍必須包含讀共享資源；范圍不包含讀共享資源會導致臟讀，最終導致數(shù)據(jù)的錯誤，如下圖所示，Client B最終計算的B的結(jié)果就是錯誤的。

e. 獲取鎖失敗

由于其他線程已經(jīng)獲取到了鎖，當前線程獲取鎖失敗后有3種處理方式：異常拋出讓用戶重試；通過自旋再次進行搶鎖；發(fā)布訂閱，訂閱鎖釋放消息；在并發(fā)度低的場景下異常拋出以及自旋搶鎖都可以，在高并發(fā)場景下異常拋出和自旋搶鎖都不可取。

② MySQL數(shù)據(jù)庫鎖CR點

a. 數(shù)據(jù)庫版本號樂觀鎖

在數(shù)據(jù)庫的表中需要包含一個數(shù)字類型的字段version，讀取數(shù)據(jù)時把version字段讀出來，更新數(shù)據(jù)時判斷當前version是否等于讀取出來的version，并對當前version+1；如果等于就更新成功，不等于表示數(shù)據(jù)已過期更新失敗。例如以積分體系為例，存在多種場景增加積分，通過樂觀鎖來保證數(shù)據(jù)的正確性。

樂觀鎖CR注意點:

• where 條件一定要命中索引(最好是主鍵或者唯一索引)，否則會鎖表；
• update table set 中必須要包含version = version + 1；
• update 返回結(jié)果為0時，一定要根據(jù)業(yè)務場景進行相應的處理，自主重試或者拋異常。

b. 基于MySQL鎖表

其實現(xiàn)原理是：創(chuàng)建一張鎖表，對臨界資源做唯一性約束，通過增加一條記錄對某一資源上鎖，釋放鎖時刪除記錄；一般不推薦此種用法。

2）并發(fā)測試

并發(fā)測試總體上可以分為3大類：

a. 復雜的并發(fā)場景，一次請求共享資源存在多個，且前后存在各種依賴關(guān)系，此種場      景適合于鏈路級別壓測，壓測模型需要精心設計。

b. 單一并發(fā)場景，一個共享資源，可以處理多次，例如：扣除某個商品的庫存，可以       反復調(diào)用。

• 可以通過接口壓測的方式進行測試，通過查看最終數(shù)據(jù)是否會存在與預期不一致情況即可；
• 壓測工具：jmeter 即可進行壓測（集團可直接采用pas-server進行壓測，方便快捷）；

c. 單一并發(fā)場景，一個共享資源，且只能處理1次，例如：用戶只有一次抽獎機會，        連續(xù)點2次會不會抽2次；

• 可以利用JVM的并發(fā)函數(shù)CountDownLatch，CyclicBarrier等，CountDownLatch片段代碼：

 public void invokeAllTask(ConcurrencyRequest request, Runnable task) {
        final CountDownLatch startCountDownLatch = new CountDownLatch(1);
        final CountDownLatch endCountDownLatch = new CountDownLatch(request.getConcurrency());
        for (int i = 0; i < request.getConcurrency(); i++) {
            Thread t = new Thread(() -> {
                try {
                    startCountDownLatch.await();
                    try {
                        task.run();
                    } finally {
                        endCountDownLatch.countDown();
                    }
                } catch (Exception ex) {
                    log.error("異常", ex);
                }
            });
            t.start();
        }
        startCountDownLatch.countDown();
        try {
            endCountDownLatch.await();
        } catch (InterruptedException ex) {
            log.error("線程異常中斷", ex);
        }
    }

• 利用jmeter的定時器 Synchronizing Timer也可以實現(xiàn)此功能。

3、事后保障

1）數(shù)據(jù)對賬

數(shù)據(jù)對賬(數(shù)據(jù)一致性校驗)是我們在系統(tǒng)上線后對并發(fā)問題的最后一道防線，通過對賬來識別我們的數(shù)據(jù)的不一致性問題；壓測有成本，且受技巧熟練度和壓測設計的影響，不一定能暴露問題；如果被測場景評估并發(fā)問題的發(fā)生概率極低，即使發(fā)生了影響也比較小，此時review+對賬方式也不失為一種好的選擇；

如何進行對賬，不同的業(yè)務場景有不同的對賬方法，例如：

• 互動積分體系每個用戶的扣除以及增加積分都會落流水表；每個用戶目前有多少積分都會放在積分表；只需要把流水表的積分加總和積分表的積分進行對賬；
• 互動任務體系，一筆訂單只能推進一個任務，對賬只需要檢查任務記錄中一筆訂單是否存在多條記錄；

select count(*)  as task_count,
       scene_code,
       order_id
  from task_record
 where unique_id is not null
 group by scene_code,
         order_id
having count(*)> 1

四、總結(jié)

作為質(zhì)量保障同學一定要時刻繃著一根弦，當前場景下是否會存在并發(fā)問題；并發(fā)問題的識別簡單而言就是是否存在同時更新同一個數(shù)據(jù)，如果是就一定要注意開發(fā)同學是否處理了并發(fā)，并發(fā)的實現(xiàn)主要是上面闡述的幾種，然后按照場景進行分析即可；關(guān)于并發(fā)場景的質(zhì)量保障，大體原則可以概括為如下：

• 梳理并發(fā)場景；
• 帶著注意點CR 代碼；
• 并發(fā)測試（非銀彈，不是所有場景都具備可測性）；
• 監(jiān)控對賬進行兜底識別并發(fā)問題。

新聞名稱：三種方法+三種選型，用分布式鎖還怕啥并發(fā)問題呀？
本文路徑：http://uogjgqi.cn/article/djeeigs.html