分佈式鎖的必要性
在單機時代，雖然不需要分佈式鎖，但也面臨過類似的問題，只不過在單機的情況下，如果有多個線程要同時訪問某個共享資源的時候，我們可以採用線程間加鎖的機制，即當某個線程獲取到這個資源後，就立即對這個資源進行加鎖，當使用完資源之後，再解鎖，其它線程就可以接着使用了。例如，在JAVA中，甚至專門提供了一些處理鎖機制的一些API（synchronize/Lock等）
類似的，當多個進程訪問共享資源時，不同進程內的鎖無關聯，無法進行資源的排他控制；因此必須引入分佈式鎖，通過鎖機制來讓多客戶端互斥的對共享資源進行訪問。
分佈式鎖要滿足哪些要求呢？
排他性：在同一時間只會有一個客戶端能獲取到鎖，其它客戶端無法同時獲取
避免死鎖：這把鎖在一段有限的時間之後，一定會被釋放（正常釋放或異常釋放）
高可用：獲取或釋放鎖的機制必須高可用且性能佳
分佈式鎖實現的三種方式
數據庫方式
基於數據庫來做分佈式鎖的話，通常有兩種做法：
基於數據庫的樂觀鎖
基於數據庫的悲觀鎖
我們先來看一下如何基於「樂觀鎖」來實現：
樂觀鎖機制其實就是在數據庫表中引入一個版本號（version）字段來實現的。
當我們要從數據庫中讀取數據的時候，同時把這個version字段也讀出來，如果要對讀出來的數據進行更新後寫回數據庫，則需要將version加1，同時將新的數據與新的version更新到數據表中，且必須在更新的時候同時檢查目前數據庫裏version值是不是之前的那個version，如果是，則正常更新。如果不是，則更新失敗，說明在這個過程中有其它的進程去更新過數據了。
如圖，假設同一個賬戶，用戶A和用戶B都要去進行取款操作，賬戶的原始餘額是2000，用戶A要去取1500，用戶B要去取1000，如果沒有鎖機制的話，在併發的情況下，可能會出現餘額同時被扣1500和1000，導致最終餘額的不正確甚至是負數。但如果這裏用到樂觀鎖機制，當兩個用戶去數據庫中讀取餘額的時候，除了讀取到2000餘額以外，還讀取了當前的版本號version=1，等用戶A或用戶B去修改數據庫餘額的時候，無論誰先操作，都會將版本號加1，即version=2，那麼另外一個用戶去更新的時候就發現版本號不對，已經變成2了，不是當初讀出來時候的1，那麼本次更新失敗，就得重新去讀取最新的數據庫餘額。
再來看一下如何基於「悲觀鎖」來實現：
悲觀鎖也叫作排它鎖，在Mysql中是基於 for update 來實現加鎖的，例如：
//鎖定的方法-僞代碼publicbooleanlock(){ connection.setAutoCommit(false)for(){ result =select*fromuserwhereid =100forupdate;if(result){//結果不爲空，//則說明獲取到了鎖returntrue; }//沒有獲取到鎖，繼續獲取sleep(1000); }returnfalse;}//釋放鎖-僞代碼connection.commit();
上面的示例中，user表中，id是主鍵，通過 for update 操作，數據庫在查詢的時候就會給這條記錄加上排它鎖。
（需要注意的是，在InnoDB中只有字段加了索引的，纔會是行級鎖，否者是表級鎖，所以這個id字段要加索引）
當這條記錄加上排它鎖之後，其它線程是無法操作這條記錄的。
那麼，這樣的話，我們就可以認爲獲得了排它鎖的這個線程是擁有了分佈式鎖，然後就可以執行我們想要做的業務邏輯，當邏輯完成之後，再調用上述釋放鎖的語句即可。
redis 實現方式
基於Redis實現的鎖機制，主要是依賴redis自身的原子操作，例如：
SETuser_key user_value NX PX100
redis從2.6.12版本開始，SET命令才支持這些參數：
NX：只在在鍵不存在時，纔對鍵進行設置操作，SET key value NX 效果等同於 SETNX key value
PX millisecond：設置鍵的過期時間爲millisecond毫秒，當超過這個時間後，設置的鍵會自動失效
上述代碼示例是指，當redis中不存在user_key這個鍵的時候，纔會去設置一個user_key鍵，並且給這個鍵的值設置爲 user_value，且這個鍵的存活時間爲100ms
爲什麼這個命令可以幫我們實現鎖機制呢？
因爲這個命令是只有在某個key不存在的時候，纔會執行成功。那麼當多個進程同時併發的去設置同一個key的時候，就永遠只會有一個進程成功。
當某個進程設置成功之後，就可以去執行業務邏輯了，等業務邏輯執行完畢之後，再去進行解鎖。
解鎖很簡單，只需要刪除這個key就可以了，不過刪除之前需要判斷，這個key對應的value是當初自己設置的那個。
另外，針對redis集羣模式的分佈式鎖，可以採用redis的Redlock機制。
zookeeper實現方式
其實基於ZooKeeper，就是使用它的臨時有序節點來實現的分佈式鎖。
原理就是：當某客戶端要進行邏輯的加鎖時，就在zookeeper上的某個指定節點的目錄下，去生成一個唯一的臨時有序節點， 然後判斷自己是否是這些有序節點中序號最小的一個，如果是，則算是獲取了鎖。如果不是，則說明沒有獲取到鎖，那麼就需要在序列中找到比自己小的那個節點，並對其調用exist()方法，對其註冊事件監聽，當監聽到這個節點被刪除了，那就再去判斷一次自己當初創建的節點是否變成了序列中最小的。如果是，則獲取鎖，如果不是，則重複上述步驟。
如圖，locker是一個持久節點，node_1/node_2/…/node_n 就是上面說的臨時節點，由客戶端client去創建的。
client_1/client_2/…/clien_n 都是想去獲取鎖的客戶端。以client_1爲例，它想去獲取分佈式鎖，則需要跑到locker下面去創建臨時節點（假如是node_1）創建完畢後，看一下自己的節點序號是否是locker下面最小的，如果是，則獲取了鎖。如果不是，則去找到比自己小的那個節點（假如是node_2），找到後，就監聽node_2，直到node_2被刪除，那麼就開始再次判斷自己的node_1是不是序列中最小的，如果是，則獲取鎖，如果還不是，則繼續找一下一個節點。
參考鏈接：https://www.jianshu.com/p/31d3de863ff7