在分布式鎖的實現方案中，通常就是數據庫、Redis 以及 Zookeeper 這三種，關于分布式鎖的多種實現方式及原理我們這里不展開了。

圖片

本文主要聚焦 Redis 的分布式鎖和Zookeeper 的分布式鎖之間的區別，以及如何選擇。

其實在功能上，Redis 的分布式鎖和 ZK 的分布式鎖都能實現我們想要的功能，鎖的互斥、重入等等。他們主要有以下幾個區別：

性能區別

在性能方面，Redis 是基于內存存儲的，而 ZK 是基于磁盤存儲的，所以，在性能上，Redis 要比 ZK 更好一些。

自動釋放

ZK 的鎖的實現原理是基于客戶端和服務端的連接來保證的，一旦連接斷了，鎖就會被自動釋放。而 Redis 的鎖是需要自己主動加鎖和解鎖的，除非達到了超時時間，否則不會自動釋放。

所以，ZK 的分布式鎖可以更好的應對客戶端崩潰的情況，一旦客戶端崩潰，鎖就會釋放，而 Redis 實現的分布式鎖，一旦客戶端崩潰了，就沒有人去進行釋放了，只能等超時。

鎖能自動釋放有啥好處？除了提升并發度以外，還有個好處就是可以減少死鎖發生的概率。因為鎖釋放了，所以就不會出現死鎖了。

一致性&可用性要求（CAP）

我們分別介紹過關于 Redis和 Zookeeper 的 CAP 的實現情況，我們知道ZK 是一個 CP 的系統，也就是他是保證強一致性的，而 Redis 是一個 AP 的系統，它是保證可用性的。

ZK 會犧牲可用性來保證數據的一致性，即出現部分節點宕機后，集群中少于一半的節點后，或者集群正在進行 master 選舉時，都會拒絕新的寫請求，導致無法加鎖。

而Redis 會犧牲一致性性來保證可用性，即 Redis 的集群中在做數據同步時，如果出現網絡延遲，那么即使多個節點上面的數據不一樣，客戶端也可以正常的進行寫入和讀取。

那么，在使用 ZK 的分布式鎖的時候，不會存在鎖丟失的情況，也就是說不太會出現因為鎖丟失而導致并發的情況。但是，可能會出現短暫的無法加鎖的情況。

而在使用 Redis 的分布式鎖的時候，除非集群都掛了，要不然不太會出現無法加鎖的情況。但是可能會出現鎖丟失的情況，或者說是重復加鎖的情況，我們介紹 RedLock 的時候提到的單點故障的問題。（詳見我八股文中關于《什么是RedLock，他解決了什么問題》）

做個總結

Redis 實現的分布式鎖、性能更好，可用性更高。ZK 實現的分布式鎖可以自動釋放，減少死鎖出現的概率，并且他的一致性更有保障。

所以，如果你的分布式鎖使用場景，對性能要求更高，可以犧牲一點一致性，那么就選擇 Redis的分布式鎖。而如果你的場景對性能要求沒那么高，但是對一致性要求非常高，那么則可以選擇 Zookeeper

But

凡事都有個 but，下面就是一些經驗之談了。

其實，如果你對可用性的要求高的話，用 Redis 也行，因為有個 RedLock，他的機制和 zk 很像，都是通過半數以上提交這種方式來避免因為單點問題而導致鎖重復的。

但是，RedLock 其實我也不建議大家用，并且 ZK的分布式鎖我其實也不建議大家用。就直接用 Redis 就好了。(詳見我的八股文中《Redisson 中為什么要廢棄 RedLock，該用啥？》）

為啥呢？因為一般來說，我們在用分布式鎖的時候，對性能要求肯定很高的，如果不高的話，你直接用數據庫的悲觀鎖就好了。沒必要用分布式鎖。

而且，往往我們在用分布式鎖的時候，同時會伴隨著冪等性判斷、以及數據庫兜底的唯一性約束的校驗。所以，即使出現了極端情況，因為 Redis 的一致性沒保證好，導致重復加鎖了，我們也能在后續的環節中識別并防止并發。

而 Redis 的不可用的問題其實可以通過哨兵、集群等運維手段來解決的，所以，發生的概率本來就極低。所以說，日常開發的時候，只要我們把冪等判斷、唯一性約束做好，對賬最好，用 Redis 是最簡單，高效的辦法。

而且，Redis 作為一個緩存框架，很多應用都會直接依賴，直接用SETNX 或者 Redisson 加鎖不要太方便。而 Zookeeper，很多都是中間件在使用他， 真正的業務應用依賴的很少的，多引入一個底層中間件，對系統來說也會提升復雜度，減少整體的穩定性的。

除非你真的完全接受不了不一致性，完全不能接受重復加鎖，有很愿意依賴 zookeeper，那當我沒說，我認為這種情況少之又少。