如何將分散式鎖封裝的更優雅

猿天地發表於2020-09-01
分散式封裝

分散式鎖通常有很多選擇，基於 Redis 的，基於 Zookeeper 的，基於資料庫等等方案。

Redis 用於快取資料，在專案中都有使用，所以使用 Redis 來做分散式鎖的會稍微多些。

如果用 Redis 來做鎖，可以直接用開源的方案，比如redisson。

最常見的使用方式如下所示：

RLock lock = redisson.getLock("anyLock");
lock.lock();
run();
lock.unlock();

獲取鎖物件，呼叫 lock()加鎖，執行業務邏輯，呼叫 unlock()釋放鎖。

儘管框架提供的使用方式已經很簡潔了，但是我們還是有必要對鎖做一層包裝。做包裝的目的是為了提高擴充套件性和易用性。

抽象介面

如果說我們直接使用 redisson 的原生 API 做加鎖，那麼很多地方都會出現 RLock 相關的程式碼，突然有一天，由於某些原因，需要將鎖進行替換，這個時候改動的範圍就比較大了。每個使用了 RLock 的地方都得改。

如下圖：很多 Service 都用到了 RLock.lock()方法，當我們需要替換鎖的時候，所有涉及到的類和方法都得修改，改動的點如紅色部分所示。

所以我們需要做一層抽象，可以定義一個 DistributedLock 介面來提供鎖相關的能力，提供多種實現，這樣方便替換和擴充套件。

如下圖：每個 Service 中都是用的 DistributedLock 介面來加鎖，當我們需要替換鎖的實現時，使用的地方不需要改動，只需要替換 DistributedLock 的實現即可。

自動釋放

自動釋放指的是對於加鎖之後，業務邏輯執行完畢需要自動關閉鎖。按照前面 Redisson 的方式我們需要手動呼叫 unlock()來釋放持有的鎖。

當然 Redisson 也提供了超時釋放的功能，正常情況下肯定是業務執行完畢就要釋放鎖了，同一個鎖的下個請求才能繼續接著處理。

手動釋放資源最容易出現的問題就是忘記釋放，所以在 JDK7 中引入了 try-with-resources 來自動釋放資源，相信大家都很熟悉。

所以我們在封裝的時候，儘量不要讓使用者去手動釋放，減少出錯的概率。對於有結果的我們可以使用 Supplier 來傳遞你的邏輯，對於沒有返回結果的可以用 Runnable 來傳遞你的邏輯。

/**
 * 加鎖
 * @param key 鎖Key
 * @param waitTime 嘗試加鎖，等待時間 (ms)
 * @param leaseTime 上鎖後的失效時間 (ms)
 * @param success 鎖成功執行的邏輯
 * @param fail 鎖失敗執行的邏輯
 * @return
 */
<T> T lock(String key, int waitTime, int leaseTime, Supplier<T> success, Supplier<T> fail);

使用：

String result = distributedLock.lock("1001", 1000, () -> {
    System.out.println("進來了。。。。");
    try {
        Thread.sleep(1000);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    return "success";
}, () -> {
    System.out.println("加鎖失敗。。。。");
    return "fail";
});

容災處理

另一個需要注意的問題就是鎖的可用性，萬一對應的 Redis 出問題了，這個時候去加鎖肯定會失敗，如果不做任何處理，就會影響正常的業務操作，導致業務不可用。

我們除了實現 Redis 的鎖之外，還可以實現其他的鎖，比如資料庫鎖。當 Redis 鎖不可用的時候降級為資料庫鎖，雖然效能有所影響，但是不會影響業務。

如果資料庫鎖也不可用了（題外話：所有都不可用可能性非常小），那還是讓業務操作失敗比較好。因為我們用加鎖的場景，肯定是為了防止併發場景帶來的問題，如果當鎖不可用時，你將異常消費了，讓業務操作繼續下去，就有可能出現沒有加鎖的業務問題。

當然監控也非常需要，Redis, 資料庫等監控。在出故障的時候，及時有人員介入。

監控體系

Redis, 資料庫，Zookeeper 這些承載分散式實現的中介軟體的監控肯定是必須要有的。另一個監控就是更細粒度的對應鎖這個動作的監控。

比如加鎖的時間，釋放鎖的時間，在鎖裡面執行業務的時間，鎖的併發量，執行次數，加鎖失敗的次數。

這些資料指標都非常重要，能夠幫助你及時發現問題。比如 10 秒內幾百次加鎖失敗，都降級成了資料庫鎖，這個時候你收到了警報，一看就知道 Redis 出問題了，及時解決。

監控方式就隨便了，每個公司都不一樣，你可以暴露資料給 Prometheus 抓取，也可以整合 Cat 做好埋點，只要能監控，能告警就可以了。

關於作者：尹吉歡，簡單的技術愛好者，《Spring Cloud 微服務-全棧技術與案例解析》, 《Spring Cloud 微服務 入門 實戰與進階》作者, 公眾號猿天地發起人。

我整理了一份很全的學習資料，感興趣的可以微信搜尋「猿天地」，回覆關鍵字 「學習資料」獲取我整理好了的 Spring Cloud，Spring Cloud Alibaba，Sharding-JDBC 分庫分表，任務排程框架 XXL-JOB，MongoDB，爬蟲等相關資料。

相關文章