先貼上石杉大神的原文連接: 分佈式鎖用Redis還是Zookeeper？
方案實現
基於Redis實現分佈式鎖可以使用Redisson綜合中間件框架, 基於Zookeeper實現分佈式鎖可以使用Curator框架
兩種方案的優缺點比較
對於 Redis 的分佈式鎖而言，它有以下缺點：
- 它獲取鎖的方式簡單粗暴，獲取不到鎖直接不斷嘗試獲取鎖，比較消耗性能。
- 另外來說的話，Redis 的設計定位決定了它的數據並不是強一致性的，在某些極端情況下，可能會出現問題。鎖的模型不夠健壯。
- 即便使用 Redlock 算法來實現，在某些複雜場景下，也無法保證其實現 100% 沒有問題，關於 Redlock 的討論可以看 How to do distributed locking。
- Redis 分佈式鎖，其實需要自己不斷去嘗試獲取鎖，比較消耗性能。
但是另一方面使用 Redis 實現分佈式鎖在很多企業中非常常見，而且大部分情況下都不會遇到所謂的“極端複雜場景”。
所以使用 Redis 作爲分佈式鎖也不失爲一種好的方案，最重要的一點是 Redis 的性能很高，可以支撐高併發的獲取、釋放鎖操作。
對於 ZK 分佈式鎖而言:
- ZK 天生設計定位就是分佈式協調，強一致性。鎖的模型健壯、簡單易用、適合做分佈式鎖。
- 如果獲取不到鎖，只需要添加一個監聽器就可以了，不用一直輪詢，性能消耗較小。
但是 ZK 也有其缺點：如果有較多的客戶端頻繁的申請加鎖、釋放鎖，對於 ZK 集羣的壓力會比較大。
小結：綜上所述，Redis 和 ZK 都有其優缺點。我們在做技術選型的時候可以根據這些問題作爲參考因素。
一些建議
通過前面的分析，實現分佈式鎖的兩種常見方案：Redis 和 ZK，他們各有千秋。應該如何選型呢？
就個人而言的話，我比較推崇 ZK 實現的鎖：因爲 Redis 是有可能存在隱患的，可能會導致數據不對的情況。但是，怎麼選用要看具體在公司的場景了。
如果公司裏面有 ZK 集羣條件，優先選用 ZK 實現，但是如果說公司裏面只有 Redis 集羣，沒有條件搭建 ZK 集羣。
那麼其實用 Redis 來實現也可以，另外還可能是系統設計者考慮到了系統已經有 Redis，但是又不希望再次引入一些外部依賴的情況下，可以選用 Redis。這個是要系統設計者基於架構來考慮了。