在分析分布式鎖的三種實現方式之前，先了解一下分布式鎖應該具備哪些條件： 1. 在分布式系統環境下，一個方法在同一時間只能被一個機器的一個線程執行； 2. 高可用的獲取鎖與釋放鎖； 3. 高性能的獲取鎖與釋放鎖； 4. 具備可重入特性； 5. 具備鎖失效機制，防止死鎖； 6. 具備非阻塞鎖特性，即沒有獲取到鎖將直接返回獲取鎖失敗。 分布式的CAP理論告訴我們“任何一個分布式系統都無法同時滿足一致性（Consistency）、可用性（Availability）和分區容錯性（Partition tolerance），最多只能同時滿足兩項。”所以，很多系統在設計之初就要對這三者做出取舍。在互聯網領域的絕大多數的場景中，都需要犧牲強一致性來換取系統的高可用性，系統往往只需要保證“最終一致性”，只要這個最終時間是在用戶可以接受的范圍內即可。 通常分布式鎖以單獨的服務方式實現，目前比較常用的分布式鎖實現有三種： * 基于數據庫實現分布式鎖。 * 基于緩存（redis，memcached，tair）實現分布式鎖。 * 基于Zookeeper實現分布式鎖。 盡管有這三種方案，但是不同的業務也要根據自己的情況進行選型，他們之間沒有最好只有更適合！ #### 1、 基于數據庫的實現方式 基于數據庫的實現方式的核心思想是：在數據庫中創建一個表，表中包含方法名等字段，并在方法名字段上創建唯一索引，想要執行某個方法，就使用這個方法名向表中插入數據，成功插入則獲取鎖，執行完成后刪除對應的行數據釋放鎖。 創建一個表： ``` DROP TABLE IF EXISTS `method_lock`; CREATE TABLE `method_lock` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '主鍵', `method_name` varchar(64) NOT NULL COMMENT '鎖定的方法名', `desc` varchar(255) NOT NULL COMMENT '備注信息', `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uidx_method_name` (`method_name`) USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8 COMMENT='鎖定中的方法'; ``` 想要執行某個方法，就使用這個方法名向表中插入數據： ``` INSERT INTO method_lock (method_name, desc) VALUES ('methodName', '測試的methodName'); ``` 因為我們對method\_name做了唯一性約束，這里如果有多個請求同時提交到數據庫的話，數據庫會保證只有一個操作可以成功，那么我們就可以認為操作成功的那個線程獲得了該方法的鎖，可以執行方法體內容。 成功插入則獲取鎖，執行完成后刪除對應的行數據釋放鎖： ``` delete from method_lock where method_name ='methodName'; ``` 注意：這里只是使用基于數據庫的一種方法，使用數據庫實現分布式鎖還有很多其他的用法可以實現！ 使用基于數據庫的這種實現方式很簡單，但是對于分布式鎖應該具備的條件來說，它有一些問題需要解決及優化： 1. 因為是基于數據庫實現的，數據庫的可用性和性能將直接影響分布式鎖的可用性及性能，所以，數據庫需要雙機部署、數據同步、主備切換； 2. 不具備可重入的特性，因為同一個線程在釋放鎖之前，行數據一直存在，無法再次成功插入數據，所以，需要在表中新增一列，用于記錄當前獲取到鎖的機器和線程信息，在再次獲取鎖的時候，先查詢表中機器和線程信息是否和當前機器和線程相同，若相同則直接獲取鎖； 3. 沒有鎖失效機制，因為有可能出現成功插入數據后，服務器宕機了，對應的數據沒有被刪除，當服務恢復后一直獲取不到鎖，所以，需要在表中新增一列，用于記錄失效時間，并且需要有定時任務清除這些失效的數據； 4. 不具備阻塞鎖特性，獲取不到鎖直接返回失敗，所以需要優化獲取邏輯，循環多次去獲取。 5. 在實施的過程中會遇到各種不同的問題，為了解決這些問題，實現方式將會越來越復雜；依賴數據庫需要一定的資源開銷，性能問題需要考慮。 #### 2、基于Redis的實現方式 選用Redis實現分布式鎖原因： 1. Redis有很高的性能； 2. Redis命令對此支持較好，實現起來比較方便; 主要實現方式: 1. SET lock currentTime+expireTime EX 600 NX，使用set設置lock值，并設置過期時間為600秒，如果成功，則獲取鎖； 2. 獲取鎖后，如果該節點掉線，則到過期時間ock值自動失效； 3. 釋放鎖時，使用del刪除lock鍵值； 使用redis單機來做分布式鎖服務，可能會出現單點問題，導致服務可用性差，因此在服務穩定性要求高的場合，官方建議使用redis集群（例如5臺，成功請求鎖超過3臺就認為獲取鎖），來實現redis分布式鎖。 優點:性能高，redis可持久化，也能保證數據不易丟失,redis集群方式提高穩定性。 缺點:使用redis主從切換時可能丟失部分數據。 #### 3、基于ZooKeeper的實現方式 ZooKeeper是一個為分布式應用提供一致性服務的開源組件，它內部是一個分層的文件系統目錄樹結構，規定同一個目錄下只能有一個唯一文件名。基于ZooKeeper實現分布式鎖的步驟如下： 1. 創建一個目錄mylock； 2. 線程A想獲取鎖就在mylock目錄下創建臨時順序節點； 3. 獲取mylock目錄下所有的子節點，然后獲取比自己小的兄弟節點，如果不存在，則說明當前線程順序號最小，獲得鎖； 4. 線程B獲取所有節點，判斷自己不是最小節點，設置監聽比自己次小的節點； 5. 線程A處理完，刪除自己的節點，線程B監聽到變更事件，判斷自己是不是最小的節點，如果是則獲得鎖。 這里推薦一個Apache的開源庫Curator，它是一個ZooKeeper客戶端，Curator提供的InterProcessMutex是分布式鎖的實現，acquire方法用于獲取鎖，release方法用于釋放鎖。 優點：具備高可用、可重入、阻塞鎖特性，可解決失效死鎖問題。 缺點：因為需要頻繁的創建和刪除節點，性能上不如Redis方式。 上面的三種實現方式，沒有在所有場合都是完美的，所以，應根據不同的應用場景選擇最適合的實現方式。 在分布式環境中，對資源進行上鎖有時候是很重要的，比如搶購某一資源，這時候使用分布式鎖就可以很好地控制資源。