採用資料庫 不建議 效能不好 jdbc
基於redis實現分布式鎖（setnx）setnx也可以存入key，如果存入key成功返回1，如果存入的key已經存在了，返回0.
基於zookeeper實現分布式鎖 zookeeper是乙個分布式協調工具，在分布式解決方案中。
多個客戶端（jvm），同時在zk上建立相同的乙個臨時節點，因為臨時節點路徑是保證唯一，只要誰能夠建立節點成功，誰就能夠獲取到鎖，沒有建立成功節點，就會進行等待，當釋放鎖的時候，採用事件通知給客戶端重新獲取鎖的資源。
實現分布式鎖最終是通過什麼方式？（相同點）
在集群環境下，保證只允許有乙個jvm進行執行。從技術上分析（區別)
redis 是nosql資料，主要特點快取
zookeeper是分布式協調工具，主要用於分布式解決方案
實現思路（ 區別）
核心通過獲取鎖、釋放鎖、死鎖問題zookeeper
多個客戶端（jvm），會在zookeeper上建立同乙個臨時節點，因為zookeeper節點命名路徑保證唯一，不允許出現重複，只要誰能夠先建立成功，誰能夠獲取到鎖。多個客戶端（jvm），會在redis使用setnx命令建立相同的乙個key，因為redis的key保證唯一，不允許出現重複，只要誰能夠先建立成功，誰能夠獲取到鎖。zookeeper
使用直接關閉臨時節點session會話連線，因為臨時節點生命週期與session會話繫結在一塊，如果session會話連線關閉的話，該臨時節點也會被刪除。
這時候客戶端使用事件監聽，如果該臨時節點被刪除的話，重新進入盜獲取鎖的步驟。
在釋放鎖的時候，為了確保是鎖的一致性問題，在刪除的redis 的key時候，需要判斷同乙個鎖的id，才可以刪除。效能角度考慮
因為redis是nosql資料庫，相對比來說redis比zookeeper效能要好。
可靠性從可靠性角度分析，zookeeper可靠性比redis更好。
因為redis有效期不是很好控制，可能會產生有效期延遲，zookeeper就不一樣，因為zookeeper臨時節點先天性可控的有效期，所以相對來說zookeeper比redis更好
zookeeper
使用會話有效期方式解決死鎖現象。是對key設定有效期解決死鎖現象分布式鎖解決方案
分布式鎖三種實現方式 1.基於資料庫實現分布式鎖 2.基於快取 redis等 實現分布式鎖 3.基於zookeeper實現分布式鎖 1.悲觀鎖 利用select where for update 排他鎖 注意 其他附加功能與實現一基本一致，這裡需要注意的是 where name lock name欄...
zk分布式鎖解決方案
思路 加鎖時，在指定路徑建立臨時節點 臨時節點避免死鎖 於是只有乙個執行緒能建立成功 等待時，其他建立節點失敗的執行緒，會watch指定路徑的刪除事件，一旦事件觸發，說明臨時節點被刪除，執行緒可以繼續去獲取鎖 解鎖時，當前執行緒刪除它建立的節點 public class zookeeperdistr...
分布式複習 redis 解決方案
如何保證redis快取和資料庫中資料的一致性 方案一 先刪除快取，再跟新資料庫 併發情況下，乙個更新，乙個查詢，更新操作刪除快取後，查詢操作沒有命中快取，先把老資料讀出來後放到快取中，然後更新操作更新了資料庫。於是，在快取中的資料還是老的資料，導致快取中的資料是髒的，而且還一直這樣髒下去了。方案二 ...