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

圖片

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

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

性能區(qū)別

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

自動釋放

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

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

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

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

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

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

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

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

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

做個總結(jié)

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

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

But

凡事都有個 but，下面就是一些經(jīng)驗之談了。

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

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

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

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

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

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

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