在單機時代，雖然不需要分布式鎖，但也面臨過類似的問題，只不過在單機的情況下，如果有多個線程要同時訪問某個共享資源的時候，我們可以采用線程間加鎖的機制，即當某個線程獲取到這個資源后，就立即對這個資源進行加鎖，當使用完資源之后，再解鎖，其它線程就可以接著使用了。例如，在JAVA中，甚至專門提供了一些處理鎖機制的一些API(synchronize/Lock等)。

但是到了分布式系統的時代，這種線程之間的鎖機制，就沒作用了，系統可能會有多份并且部署在不同的機器上，這些資源已經不是在線程之間共享了，而是屬于進程之間共享的資源。

因此，為了解決這個問題，我們就必須引入分布式鎖。分布式鎖是指在分布式的部署環境下，通過鎖機制來讓多客戶端互斥的對共享資源進行訪問。

目前比較常見的分布式鎖實現方案有以下幾種：

基于數據庫，如MySQL

基于緩存，如Redis

基于Zookeeper、etcd等

我們在討論使用分布式鎖的時候往往首先排除掉基于數據庫的方案，本能的會覺得這個方案不夠“高級”。從性能的角度考慮，基于數據庫的方案性能確實不夠優異，整體性能對比：緩存 > Zookeeper、etcd > 數據庫。也有人提出基于數據庫的方案問題很多，不太可靠。筆者認為采用哪種方案是要基于使用場景來看的，選擇哪種方案，合適最重要。

我這里引用一下之前文章中的一個應用場景——分配任務場景。在這個場景中，由于是公司的業務后臺系統，主要是用于審核人員的審核工作，并發量并不是很高，而且任務的分配規則設計成了通過審核人員每次主動的請求拉取，然后服務端從任務池中隨機的選取任務進行分配。這個場景看到這里你會覺得比較單一，但是實際的分配過程中，由于涉及到了按用戶聚類的問題，所以要比我描述的復雜，但是這里為了說明問題，大家可以把問題簡單化理解。那么在使用過程中，主要是為了避免同一個任務同時被兩個審核人員獲取到的問題。在這個場景下使用基于數據庫的方案就比較合理。

再補充一下，比如某一個服務它下游依賴數據庫來做一些數據的讀寫操作，模型如下圖所示：

一般服務也是多實例部署，如果多個實例需要操作同一份數據的時候(比如前面所說的同一個任務同時被兩個審核人員獲取到的問題)，自然而然的引入了分布式鎖。不過此時，我們并沒有采用數據庫的方案，而是引入了Redis，模型如下圖所示：

引入Redis之后，正向的收益我就不贅述了，反向的收益是增加了系統的復雜度，對于整個服務而言，還需要多考慮1和2失效的情況。1失效是指服務模塊與Redis的交互出現了異常，這種異常不單是指無法通信的異常，也有可能是服務模塊發送請求只Redis的過程中或者Redis響應服務模塊的過程中出現的異常，整體服務需要考慮這種情況：是重試、丟棄還是采取其他措施;2失效是指Redis本身出現了異常。數據鏈路一旦變長，系統復雜度一旦變大，在出現問題的時候會阻礙故障排查以及服務恢復，從而使得服務的整體可用性下調。

反觀，如果采用數據庫的方案，那么就可以省去了這部分的復雜度，如果數據庫的方案能滿足當下場景以及可視范圍內的未來擴展，為什么還要平白地增加系統復雜度呢?大家要根據具體業務場景選擇合適的技術方案，而不是隨便找一個足夠復雜、足夠新潮的技術方案來解決業務問題。

下面我們來了解一下基于數據庫(MySQL)的方案，一般分為3類：基于表記錄、樂觀鎖和悲觀鎖。

基于表記錄

要實現分布式鎖，最簡單的方式可能就是直接創建一張鎖表，然后通過操作該表中的數據來實現了。當我們想要獲得鎖的時候，就可以在該表中增加一條記錄，想要釋放鎖的時候就刪除這條記錄。

為了更好的演示，我們先創建一張數據庫表，參考如下：

CREATE TABLE `database_lock` (
	`id` BIGINT NOT NULL AUTO_INCREMENT,
	`resource` int NOT NULL COMMENT '鎖定的資源',
	`description` varchar(1024) NOT NULL DEFAULT "" COMMENT '描述',
	PRIMARY KEY (`id`),
	UNIQUE KEY `uiq_idx_resource` (`resource`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='數據庫分布式鎖表';

當我們想要獲得鎖時，可以插入一條數據：

INSERT INTO database_lock(resource, description) VALUES (1, 'lock');

注意：在表database_lock中，resource字段做了唯一性約束，這樣如果有多個請求同時提交到數據庫的話，數據庫可以保證只有一個操作可以成功(其它的會報錯：ERROR 1062 (23000): Duplicate entry ‘1’ for key ‘uiq_idx_resource’)，那么那么我們就可以認為操作成功的那個請求獲得了鎖。

當需要釋放鎖的時，可以刪除這條數據：

DELETE FROM database_lock WHERE resource=1;

這種實現方式非常的簡單，但是需要注意以下幾點：

這種鎖沒有失效時間，一旦釋放鎖的操作失敗就會導致鎖記錄一直在數據庫中，其它線程無法獲得鎖。這個缺陷也很好解決，比如可以做一個定時任務去定時清理。

這種鎖的可靠性依賴于數據庫。建議設置備庫，避免單點，進一步提高可靠性。

這種鎖是非阻塞的，因為插入數據失敗之后會直接報錯，想要獲得鎖就需要再次操作。如果需要阻塞式的，可以弄個for循環、while循環之類的，直至INSERT成功再返回。

這種鎖也是非可重入的，因為同一個線程在沒有釋放鎖之前無法再次獲得鎖，因為數據庫中已經存在同一份記錄了。想要實現可重入鎖，可以在數據庫中添加一些字段，比如獲得鎖的主機信息、線程信息等，那么在再次獲得鎖的時候可以先查詢數據，如果當前的主機信息和線程信息等能被查到的話，可以直接把鎖分配給它。

樂觀鎖

顧名思義，系統認為數據的更新在大多數情況下是不會產生沖突的，只在數據庫更新操作提交的時候才對數據作沖突檢測。如果檢測的結果出現了與預期數據不一致的情況，則返回失敗信息。

樂觀鎖大多數是基于數據版本(version)的記錄機制實現的。何謂數據版本號?即為數據增加一個版本標識，在基于數據庫表的版本解決方案中，一般是通過為數據庫表添加一個 “version”字段來實現讀取出數據時，將此版本號一同讀出，之后更新時，對此版本號加1。在更新過程中，會對版本號進行比較，如果是一致的，沒有發生改變，則會成功執行本次操作;如果版本號不一致，則會更新失敗。

CREATE TABLE `optimistic_lock` (
	`id` BIGINT NOT NULL AUTO_INCREMENT,
	`resource` int NOT NULL COMMENT '鎖定的資源',
	`version` int NOT NULL COMMENT '版本信息',
	`created_at` datetime COMMENT '創建時間',
	`updated_at` datetime COMMENT '更新時間',
	`deleted_at` datetime COMMENT '刪除時間', 
	PRIMARY KEY (`id`),
	UNIQUE KEY `uiq_idx_resource` (`resource`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='數據庫分布式鎖表';

其中：id表示主鍵;resource表示具體操作的資源，在這里也就是特指庫存;version表示版本號。

在使用樂觀鎖之前要確保表中有相應的數據，比如：

INSERT INTO optimistic_lock(resource, version, created_at, updated_at) VALUES(20, 1, CURTIME(), CURTIME());

如果只是一個線程進行操作，數據庫本身就能保證操作的正確性。主要步驟如下：

STEP1 - 獲取資源：SELECT resource FROM optimistic_lock WHERE id = 1

STEP2 - 執行業務邏輯

STEP3 - 更新資源：UPDATE optimistic_lock SET resource = resource -1 WHERE id = 1

然而在并發的情況下就會產生一些意想不到的問題：比如兩個線程同時購買一件商品，在數據庫層面實際操作應該是庫存(resource)減2，但是由于是高并發的情況，第一個線程執行之后(執行了STEP1、STEP2但是還沒有完成STEP3)，第二個線程在購買相同的商品(執行STEP1)，此時查詢出的庫存并沒有完成減1的動作，那么最終會導致2個線程購買的商品卻出現庫存只減1的情況。

在引入了version字段之后，那么具體的操作就會演變成下面的內容：

STEP1 - 獲取資源： SELECT resource, version FROM optimistic_lock WHERE id = 1

STEP2 - 執行業務邏輯

STEP3 - 更新資源：UPDATE optimistic_lock SET resource = resource -1, version = version + 1 WHERE id = 1 AND version = oldVersion

其實，借助更新時間戳(updated_at)也可以實現樂觀鎖，和采用version字段的方式相似：更新操作執行前線獲取記錄當前的更新時間，在提交更新時，檢測當前更新時間是否與更新開始時獲取的更新時間戳相等。

樂觀鎖的優點比較明顯，由于在檢測數據沖突時并不依賴數據庫本身的鎖機制，不會影響請求的性能，當產生并發且并發量較小的時候只有少部分請求會失敗。缺點是需要對表的設計增加額外的字段，增加了數據庫的冗余，另外，當應用并發量高的時候，version值在頻繁變化，則會導致大量請求失敗，影響系統的可用性。我們通過上述sql語句還可以看到，數據庫鎖都是作用于同一行數據記錄上，這就導致一個明顯的缺點，在一些特殊場景，如大促、秒殺等活動開展的時候，大量的請求同時請求同一條記錄的行鎖，會對數據庫產生很大的寫壓力。所以綜合數據庫樂觀鎖的優缺點，樂觀鎖比較適合并發量不高，并且寫操作不頻繁的場景。

悲觀鎖

除了可以通過增刪操作數據庫表中的記錄以外，我們還可以借助數據庫中自帶的鎖來實現分布式鎖。在查詢語句后面增加FOR UPDATE，數據庫會在查詢過程中給數據庫表增加悲觀鎖，也稱排他鎖。當某條記錄被加上悲觀鎖之后，其它線程也就無法再改行上增加悲觀鎖。

悲觀鎖，與樂觀鎖相反，總是假設最壞的情況，它認為數據的更新在大多數情況下是會產生沖突的。

在使用悲觀鎖的同時，我們需要注意一下鎖的級別。MySQL InnoDB引起在加鎖的時候，只有明確地指定主鍵(或索引)的才會執行行鎖 (只鎖住被選取的數據)，否則MySQL 將會執行表鎖(將整個數據表單給鎖住)。

在使用悲觀鎖時，我們必須關閉MySQL數據庫的自動提交屬性(參考下面的示例)，因為MySQL默認使用autocommit模式，也就是說，當你執行一個更新操作后，MySQL會立刻將結果進行提交。

mysql> SET AUTOCOMMIT = 0;
Query OK, 0 rows affected (0.00 sec)

這樣在使用FOR UPDATE獲得鎖之后可以執行相應的業務邏輯，執行完之后再使用COMMIT來釋放鎖。

我們不妨沿用前面的database_lock表來具體表述一下用法。假設有一線程A需要獲得鎖并執行相應的操作，那么它的具體步驟如下：

STEP1 - 獲取鎖：SELECT * FROM database_lock WHERE id = 1 FOR UPDATE;。

STEP2 - 執行業務邏輯。

STEP3 - 釋放鎖：COMMIT。

如果另一個線程B在線程A釋放鎖之前執行STEP1，那么它會被阻塞，直至線程A釋放鎖之后才能繼續。注意，如果線程A長時間未釋放鎖，那么線程B會報錯，參考如下(lock wait time可以通過innodb_lock_wait_timeout來進行配置)：

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

上面的示例中演示了指定主鍵并且能查詢到數據的過程(觸發行鎖)，如果查不到數據那么也就無從“鎖”起了。

如果未指定主鍵(或者索引)且能查詢到數據，那么就會觸發表鎖，比如STEP1改為執行(這里的version只是當做一個普通的字段來使用，與上面的樂觀鎖無關)：

SELECT * FROM database_lock WHERE description='lock' FOR UPDATE;

或者主鍵不明確也會觸發表鎖，又比如STEP1改為執行：

SELECT * FROM database_lock WHERE id>0 FOR UPDATE;

注意，雖然我們可以顯示使用行級鎖(指定可查詢的主鍵或索引)，但是MySQL會對查詢進行優化，即便在條件中使用了索引字段，但是否真的使用索引來檢索數據是由MySQL通過判斷不同執行計劃的代價來決定的，如果MySQL認為全表掃描效率更高，比如對一些很小的表，它有可能不會使用索引，在這種情況下InnoDB將使用表鎖，而不是行鎖。

在悲觀鎖中，每一次行數據的訪問都是獨占的，只有當正在訪問該行數據的請求事務提交以后，其他請求才能依次訪問該數據，否則將阻塞等待鎖的獲取。悲觀鎖可以嚴格保證數據訪問的安全。但是缺點也明顯，即每次請求都會額外產生加鎖的開銷且未獲取到鎖的請求將會阻塞等待鎖的獲取，在高并發環境下，容易造成大量請求阻塞，影響系統可用性。另外，悲觀鎖使用不當還可能產生死鎖的情況。