一文詳解如何用MySQL/Redis/ZooKeeper實作分布式鎖-有解無憂

一個挺著啤酒肚，身穿格子衫，發際線嚴重后移的中年男子，手拿著保溫杯，胳膊夾著MacBook向你走來，看樣子是架構師級別，

面試開始， 直入正題，

面試官： 你有沒有參與過秒殺系統的設計？

我：沒有，我平時都是開發后臺管理系統、OA辦公系統、內部管理系統，從來沒有開發過秒殺系統，

面試官： 嗯...，小伙子很實誠，今天就先到這里吧，后面有訊息會主動聯系你，

后面還可能有訊息嗎？你們啥時候主動聯系過我？
實話實說的被拒，八股文背的溜反而被錄取，
好吧，等我看看一燈怎么總結的秒殺系統的八股文，

我：參與過秒殺系統，并獨立負責過秒殺系統的架構設計（【狗頭】是的，都是我設計的），

面試官： 這樣才對，這樣我才能接著往下問，你在設計秒殺系統的時候，怎么防止商品超賣？比如活動中只有一臺iPhone，最終賣出100臺，肯定不行，平臺要虧錢，

我：肯定要加鎖，不過由于秒殺系統請求量較大，一般使用分布式集群，而Java自帶Synchronized、ReentrantLock鎖只能用在單機系統中，這時候就需要用到分布式鎖，

面試官： 你提到分布式鎖，分布式鎖都有哪些作用？

八股文這就開始了，

我：我覺得分布式鎖主要有兩個作用：

保證資料的正確性：
比如：秒殺的時候防止商品超賣，表單重復提交，介面冪等性，

避免資料重復處理：
比如：調度任務在多臺機器重復執行，快取過期所有請求都去加載資料庫，

總結八股文，還得是一燈，

面試官： 小伙子總結的挺全，你知道設計一個分布式鎖，要具有哪些特性？

我：我覺得分布式鎖要具有以下這些特性：

互斥：同一時刻只能有一個執行緒獲得鎖，
可重入：當一個執行緒獲取鎖后，還可以再次獲取這個鎖，避免死鎖發生，
高可用：當小部分節點掛掉后，仍然能夠對外提供服務，
高性能：要做到高并發、低延遲，
支持阻塞和非阻塞：Synchronized是阻塞的，ReentrantLock.tryLock()就是非阻塞的
支持公平鎖和非公平鎖：Synchronized是非公平鎖，ReentrantLock(boolean fair)可以創建公平鎖

面試官： 小伙子，有點東西，你是怎么設計一個分布式鎖？

我：有幾種常用的工具都可以實作分布式鎖，
比如：關系型資料庫（例如：MySQL）、分布式資料庫（例如：Redis）、分布式協調服務框架（例如：zookeeper）

使用MySQL實作分布式鎖比較簡單，建一張表：

CREATE TABLE `distributed_lock` (
  `id` bigint unsigned NOT NULL AUTO_INCREMENT COMMENT '主鍵ID',
  `resource_name` varchar(200) NOT NULL DEFAULT '' COMMENT '資源名稱（唯一索引）',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_resource_name` (`resource_name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='分布式鎖';

獲取鎖的時候，就插入一條記錄，插入成功就代表獲取到鎖，插入失敗就代表獲取鎖失敗，

INSERT INTO distributed_lock (`resource_name`) VALUES ('資源1');

釋放鎖的時候，就洗掉這條記錄，

DELETE FROM distributed_lock WHERE resource_name = '資源1';

實作比較簡單，不過還不能用于實際生產中，有幾個問題沒有解決：

這把鎖不支持阻塞，insert失敗立即就回傳了，當然可以用while回圈直到插入成功，不過自旋也會占用CPU，
這把鎖不是可重入的，已經獲取到鎖的執行緒再次插入也會失敗，我們可以增加兩列，一列記錄獲取到鎖的節點和執行緒，另一列記錄加鎖次數，獲取鎖，次數加一，釋放鎖，次數減一，次數為零就洗掉這把鎖，
這把鎖沒有過期時間，如果業務處理失敗或者機器宕機，導致沒有釋放鎖，鎖就會一直存在，其他執行緒也無法獲取到鎖，我們可以增加一列鎖過期時間，再啟動一個異步任務掃描過期時間大于當前時間的鎖就洗掉，

就是這么麻煩，我們看一下優化之后的鎖變成什么樣了：

CREATE TABLE `distributed_lock` (
  `id` bigint unsigned NOT NULL AUTO_INCREMENT COMMENT '主鍵ID',
  `resource_name` varchar(200) NOT NULL DEFAULT '' COMMENT '資源名稱（唯一索引）',
  `owner` varchar(200) NOT NULL DEFAULT '' COMMENT '鎖持有者（機器碼+執行緒名稱）',
  `lock_count` int NOT NULL DEFAULT '0' COMMENT '加鎖次數',
  `expire_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '鎖過期時間',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_resource_name` (`resource_name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='分布式鎖';

這下應該完美了吧？不行，還有個問題：

業務邏輯沒處理完，鎖過期了怎么辦？

假如我們設定鎖過期時間是6秒，正常情況下業務邏輯可以在6秒內處理完成，但是當JVM發生FullGC或者呼叫第三方服務出現網路延遲，業務邏輯還沒處理完，鎖已經過期，被刪掉，然后被其他執行緒獲取到鎖，豈不是要出問題？

這就引入了另一個知識點“鎖續期”：

獲取鎖的同時，啟動一個異步任務，每當業務執行到三分之一時間，也就是6秒中的第2秒的時候，就自動延長鎖過期時間，繼續延長到6秒，這樣就能保證業務邏輯處理完成之前鎖不會過期，

面試官： 小伙子，分布式鎖算是讓你玩明白了，我還想繼續問，生產中一般很少用MySQL做分布式鎖，因為MySQL并發性能跟不上，剛才提到Redis也可以實作分布式鎖，你知道該怎么實作嗎？

我當然知道，八股文就要背全套，

我：使用Redis實作分布式鎖，跟使用MySQL類似，也需要解決實作程序中遇到的各種問題，不過解決方案稍有不同，

最簡單的獲取鎖方式：

// 1. 獲取鎖
redis.setnx('resource_name1', 'owner1')
// 2. 釋放鎖
redis.del('resource_name1')

當“resource_name1”不存在時，set成功，也就是獲取鎖成功，

不過還需要加上過期時間，防止沒有釋放鎖，

// 1. 獲取鎖
redis.setnx('resource_name1', 'owner1')
// 2. 增加鎖過期時間
redis.exprire('resource_name1', 6, TimeUnit.SECONDS)

又引入新問題了，兩條命令不是原子的，可能獲取鎖之后還沒來得及設定過期時間就宕機了，這該怎么辦？

好辦，在Redis 2.6.12之后，提供一條復合命令：

redis.set('resource_name1', 'owner1',"NX" "EX", 6)

還有一個問題，釋放鎖的時候，并沒有判斷鎖的持有者，有可能把其他執行緒持有的鎖給釋放了，這可不行，可以這樣做：

// 釋放鎖
if ('owner1'.equals(redis.get('resource_name1'))){
	redis.del('resource_name1')
}

這樣行不行呢？還不行，因為get和del兩條命令不是原子操作，需要引入Lua腳本把兩條命令打包成一條發給Redis執行：

String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
redis.eval(script, Collections.singletonList('resource_name1'), Collections.singletonList('owner1'))

這樣總行了吧？還不行，還有個“鎖續期”的問題沒有解決，

更簡單了，Redis客戶端Redisson已經幫我們實作續期的功能，叫“WatchDog”（看門狗），在我們呼叫lock自動喚醒“看門狗”，

面試官： 小伙子，你可真行啊，你再講一下使用zookeeper怎么實作分布式鎖？

我： zookeeper采用樹形節點，類似Linux目錄檔案結構，同一目錄下的節點名稱不能重復，