對於 redis 的分布式鎖而言，它有以下缺點：
它獲取鎖的方式簡單粗暴，獲取不到鎖直接不斷嘗試獲取鎖，比較消耗效能。
另外來說的話，redis 的設計定位決定了它的資料並不是強一致性的，在某些極端情況下，可能會出現問題。鎖的模型不夠健壯。
即便使用 redlock 演算法來實現，在某些複雜場景下，也無法保證其實現 100% 沒有問題，關於 redlock 的討論可以看 how to do distributed locking。
redis 分布式鎖，其實需要自己不斷去嘗試獲取鎖，比較消耗效能。
但是另一方面使用 redis 實現分布式鎖在很多企業中非常常見，而且大部分情況下都不會遇到所謂的「極端複雜場景」。
所以使用 redis 作為分布式鎖也不失為一種好的方案，最重要的一點是 redis 的效能很高，可以支撐高併發的獲取、釋放鎖操作。
對於 zk 分布式鎖而言:
zk 天生設計定位就是分布式協調，強一致性。鎖的模型健壯、簡單易用、適合做分布式鎖。
如果獲取不到鎖，只需要新增乙個***就可以了，不用一直輪詢，效能消耗較小。
但是 zk 也有其缺點：如果有較多的客戶端頻繁的申**鎖、釋放鎖，對於 zk 集群的壓力會比較大。
一些建議
通過前面的分析，實現分布式鎖的兩種常見方案：redis 和 zk，他們各有千秋。應該如何選型呢？
就個人而言的話，我比較推崇 zk 實現的鎖：因為 redis 是有可能存在隱患的，可能會導致資料不對的情況。但是，怎麼選用要看具體在公司的場景了。
如果公司裡面有 zk 集群條件，優先選用 zk 實現，但是如果說公司裡面只有 redis 集群，沒有條件搭建 zk 集群。
那麼其實用 redis 來實現也可以，另外還可能是系統設計者考慮到了系統已經有 redis，但是又不希望再次引入一些外部依賴的情況下，可以選用 redis。這個是要系統設計者基於架構來考慮了。
分布式鎖的實現
分布式鎖的實現方式通常有三種,第一種是基於資料庫實現分布式鎖,第二種是基於快取實現分布式鎖,第三種是基於zookeeper實現分布式鎖.第一種 基於資料庫實現分布式鎖 特點 效能較差,容易出現單點故障 鎖沒有失效時間,容易思死鎖 非阻塞式的 不可重入 第二種基於快取實現分布式鎖 鎖沒有失效時間,容易...
分布式鎖的實現
分布式鎖的實現 實現分布式鎖要滿足的條件 1.互斥性 在任意時刻，只有乙個客戶端能持有鎖 2.死鎖 不會發生死鎖，即使乙個客戶端在持有鎖的時候崩潰而沒有自己解鎖，也能保證後面其它客戶端能重新獲取鎖 3.容錯 只要大部分的節點能夠正常執行就能保證客戶端能加鎖和解鎖 1.使用資料的悲觀鎖 排它鎖 1.建...
分布式鎖的實現
分布式專案，在高併發的場景下防止資源的超載，例如秒殺超賣問題 利用了redis的乙個特性，多個使用者設定同乙個key的value，只能有乙個使用者設定成功 component public class redislock 解決死鎖問題 大教室 佔了乙個位置 放一本書 死鎖 保潔阿姨 固定時間 清理 ...