用數據庫，緩存，ZooKeeper實現分佈式鎖，你選哪一種

基於數據庫實現分佈式鎖

創建一張數據庫表，對其中一列（method_name）唯一性約束，這裡如果有多個請求同時提交到數據庫的話，數據庫會保證只有一個操作可以成功，那麼我們就可以認為操作成功的那個線程獲得了該方法的鎖，可以執行方法體內容。

問題：

1、這把鎖強依賴數據庫的可用性，數據庫是一個單點，一旦數據庫掛掉，會導致業務系統不可用。

2、這把鎖沒有失效時間，一旦解鎖操作失敗，就會導致鎖記錄一直在數據庫中，其他線程無法再獲得到鎖。

3、這把鎖只能是非阻塞的，因為數據的insert操作，一旦插入失敗就會直接報錯。沒有獲得鎖的線程並不會進入排隊隊列，要想再次獲得鎖就要再次觸發獲得鎖操作。

4、這把鎖是非重入的，同一個線程在沒有釋放鎖之前無法再次獲得該鎖。因為數據中數據已經存在了。

當然，實現有以下幾個問題，也給出一些解決方案。

• 數據庫是單點？答：搞兩個數據庫，數據之前雙向同步。一旦掛掉快速切換到備庫上。
• 沒有失效時間？答：只要做一個定時任務，每隔一定時間把數據庫中的超時數據清理一遍。
• 非阻塞的？答：搞一個while循環，直到insert成功再返回成功。
• 非重入的？答：在數據庫表中加個字段，記錄當前獲得鎖的機器的主機信息和線程信息，那麼下次再獲取鎖的時候先查詢數據庫，如果當前機器的主機信息和線程信息在數據庫可以查到的話，直接把鎖分配給他就可以了。
• 
  

基於緩存實現分佈式鎖--Redis

相比較於基於數據庫實現分佈式鎖的方案來說，基於緩存來實現在性能方面會表現的更好一點。而且很多緩存是可以集群部署的，可以解決單點問題。

在使用Redis實現分佈式鎖的時候，主要就會使用到這三個命令。

用命令介紹：

（1）SETNX

SETNX key val：當且僅當key不存在時，set一個key為val的字符串，返回1；若key存在，則什麼都不做，返回0。

（2）expire

expire key timeout：為key設置一個超時時間，單位為second，超過這個時間鎖會自動釋放，避免死鎖。

獲取鎖的時候還設置一個獲取的超時時間，若超過這個時間則放棄獲取鎖

（3）delete

delete key：刪除key

問題:

1、這把鎖沒有失效時間，一旦解鎖操作失敗，就會導致鎖記錄一直在tair中，其他線程無法再獲得到鎖。

3、這把鎖是非重入的，一個線程獲得鎖之後，在釋放鎖之前，無法再次獲得該鎖，因為使用到的key在tair中已經存在。無法再執行put操作。

解決方案：

• 沒有失效時間？tair的put方法支持傳入失效時間，到達時間之後數據會自動刪除。
• 非阻塞？while重複執行。
• 非可重入？在一個線程獲取到鎖之後，把當前主機信息和線程信息保存起來，下次再獲取之前先檢查自己是不是當前鎖的擁有者。

基於Zookeeper實現分佈式鎖

大致思想即為：每個客戶端對某個方法加鎖時，在zookeeper上的與該方法對應的指定節點的目錄下，生成一個唯一的瞬時有序節點。 判斷是否獲取鎖的方式很簡單，只需要判斷有序節點中序號最小的一個。 當釋放鎖的時候，只需將這個瞬時節點刪除即可。同時，其可以避免服務宕機導致的鎖無法釋放，而產生的死鎖問題。

基於ZooKeeper實現分佈式鎖的步驟如下：

（1）創建一個目錄mylock；

（2）線程A想獲取鎖就在mylock目錄下創建臨時順序節點；

（3）獲取mylock目錄下所有的子節點，然後獲取比自己小的兄弟節點，如果不存在，則說明當前線程順序號最小，獲得鎖；

（4）線程B獲取所有節點，判斷自己不是最小節點，設置監聽比自己次小的節點；

（5）線程A處理完，刪除自己的節點，線程B監聽到變更事件，判斷自己是不是最小的節點，如果是則獲得鎖。

• 鎖無法釋放？使用Zookeeper可以有效的解決鎖無法釋放的問題，因為在創建鎖的時候，客戶端會在ZK中創建一個臨時節點，一旦客戶端獲取到鎖之後突然掛掉（Session連接斷開），那麼這個臨時節點就會自動刪除掉。其他客戶端就可以再次獲得鎖。
• 非阻塞鎖？使用Zookeeper可以實現阻塞的鎖，客戶端可以通過在ZK中創建順序節點，並且在節點上綁定監聽器，一旦節點有變化，Zookeeper會通知客戶端，客戶端可以檢查自己創建的節點是不是當前所有節點中序號最小的，如果是，那麼自己就獲取到鎖，便可以執行業務邏輯了。
• 不可重入？使用Zookeeper也可以有效的解決不可重入的問題，客戶端在創建節點的時候，把當前客戶端的主機信息和線程信息直接寫入到節點中，下次想要獲取鎖的時候和當前最小的節點中的數據比對一下就可以了。如果和自己的信息一樣，那麼自己直接獲取到鎖，如果不一樣就再創建一個臨時的順序節點，參與排隊。
• 單點問題？使用Zookeeper可以有效的解決單點問題，ZK是集群部署的，只要集群中有半數以上的機器存活，就可以對外提供服務。

三種方案的比較

上面幾種方式，哪種方式都無法做到完美。就像CAP一樣，在複雜性、可靠性、性能等方面無法同時滿足，所以，根據不同的應用場景選擇最適合自己的才是王道。

從理解的難易程度角度（從低到高）

數據庫 > 緩存 > Zookeeper

從實現的複雜性角度（從低到高）

Zookeeper >= 緩存 > 數據庫

從性能角度（從高到低）

緩存 > Zookeeper >= 數據庫

從可靠性角度（從高到低）

Zookeeper > 緩存 > 數據庫

https://www.cnblogs.com/austinspark-jessylu/p/8043726.html

https://blog.csdn.net/xlgen157387/article/details/79036337

閱讀更多 全民學編程 的文章

關鍵字: Redis 分佈式 線程