0x01、基于MySQL實現分布式鎖
基于分布式鎖的實現，首先肯定是想單獨分離出一臺mysql數據庫，所有服務要想操作文件（共享資源），那么必須先在mysql數據庫中插入一個標志，插入標志的服務就持有了鎖，并對文件進行操作，操作完成后，主動刪除標志進行鎖釋放，其與服務會一直查詢數據庫，看是否標志有被占用，直到沒有標志占用時自己才能寫入標志獲取鎖。
但是這樣有這么一個問題，如果服務（jvm1）宕機或者卡頓了，會一直持有鎖未釋放，這樣就造成了死鎖，因此就需要有一個監視鎖進程時刻監視鎖的狀態，如果超過一定時間未釋放就要進行主動清理鎖標記，然后供其與服務繼續獲取鎖。
如果監視鎖字段進程和jvm1同時掛掉，依舊不能解決死鎖問題，于是又增加一個監視鎖字段進程，這樣一個進程掛掉，還有另一個監視鎖字段進程可以對鎖進行管理。這樣又誕生一個新的問題，兩個監視進程必須進行同步，否則對于過期的情況管理存在不一致問題。
因此存在以下問題，并且方案變得很復雜：
- 監視鎖字段進程對于鎖的監視時間周期過短，仍舊會造成多售（jvm1還沒處理完其持有的鎖就被主動銷毀，造成多個服務同時持有鎖進行操作）。
- 監視鎖字段進程對于鎖的監視時間周期過長，會造成整個服務卡頓過長，吞吐低下。
- 監視鎖字段進程間的同步問題。
- 當一個jvm持有鎖的時候，其余服務會一直訪問數據庫查看鎖，會造成其余jvm的資源浪費。
0x02、基于redis實現分布式鎖
相比較于基于數據庫實現分布式鎖的方案來說，基于緩存來實現在性能方面會表現的更好一點，Redis就是其中一種。由于Redis可以設置字段的有效期，因此可以實現自動釋放超期的鎖，不需要多個監視鎖字段進程進行鎖守護，可以依舊存在上述mysql實現中除了3以外1、2、4中的問題。
0x03、基于Zookeeper實現分布式鎖
基于以上兩種實現方式，有了基于zookeeper實現分布式鎖的方案。由于zookeeper有以下特點：
- 維護了一個有層次的數據節點，類似文件系統。
- 有以下數據節點：臨時節點、持久節點、臨時有序節點(分布式鎖實現基于的數據節點)、持久有序節點。
- zookeeper可以和client客戶端通過心跳的機制保持長連接，如果客戶端鏈接zookeeper創建了一個臨時節點，那么這個客戶端與zookeeper斷開連接后會自動刪除。
- zookeeper的節點上可以注冊上用戶事件(自定義)，如果節點數據刪除等事件都可以觸發自定義事件。
- zookeeper保持了統一視圖，各服務對于狀態信息獲取滿足一致性。
Zookeeper的每一個節點，都是一個天然的順序發號器。
在每一個節點下面創建子節點時，只要選擇的創建類型是有序（EPHEMERAL_SEQUENTIAL 臨時有序或者PERSISTENT_SEQUENTIAL 永久有序）類型，那么，新的子節點后面，會加上一個次序編號。這個次序編號，是上一個生成的次序編號加一
比如，創建一個用于發號的節點“/test/lock”，然后以他為父親節點，可以在這個父節點下面創建相同前綴的子節點，假定相同的前綴為“/test/lock/seq-”，在創建子節點時，同時指明是有序類型。如果是第一個創建的子節點，那么生成的子節點為/test/lock/seq-0000000000，下一個節點則為/test/lock/seq-0000000001，依次類推，等等。
參考來源：
https://www.cnblogs.com/jing99/p/11607094.html
