前言
在分布式系統中，分布式鎖是為了解決多實例之間的同步問題。例如master選舉，能夠獲取分布式鎖的就是master，獲取失敗的就是slave。又或者能夠獲取鎖的實例能夠完成特定的操作。
目前比較常用的分布式鎖實現有兩種，基於zookeeper實現和基於redis實現。zookeeper和redis也是生產環境中經常用到的第三方組件。下面我會分析它們的實現原理。
實現要求
實現一個分布式鎖至少要滿足下面三點要求：
- 互斥，在任何時候同一個鎖只能由一個客戶端持有。
- 不會死鎖，就算持有的客戶端異常崩潰也不會影響后續客戶端加鎖。
- 誰加鎖誰解鎖，加鎖和解鎖都必須是同一個客戶端。
zookeeper分布式鎖
在講解zookeeper的分布式鎖之前有兩個概念需要明確：
- 臨時節點：生命周期和鏈接周期一致。例如客戶端鏈接A創建了臨時節點NodeA，如果鏈接A關閉或者網絡異常斷開，那么NodeA也會跟着消失。
- 順序節點：節點名稱按照順序從小到大創建，例如先創建了000000001，那么接着創建的節點就會分配000000002。
zookeeper的分布式鎖實現原理就是利用臨時順序節點，大概流程為：
- 每個客戶端對某個功能加鎖時，在zookeeper指定目錄下生成一個唯一的臨時順序節點。
- 所有臨時節點中序號最小的節點即為當前鎖的持有者。
- 釋放鎖時將自己持有的臨時節點刪除即可。
例如，對於加鎖過程，所有的客戶端都在/lock目錄下面創建臨時節點，如果發現自己創建的臨時節點是/lock目錄中最小的節點，那么就獲取鎖成功，否則就watch比自己小的節點中的最大節點。
監控比自己小的節點中的最大節點是為了避免“驚群”效應，避免一個鎖釋放把所有等待的客戶端喚醒，但是只有一個客戶端能獲取鎖。
對於釋放鎖，只需要把自己創建的臨時順序節點刪除即可。整個過程流程圖如下：
優點：鎖安全性高，zookeeper數據不易丟失。用戶使用簡單。
缺點：性能消耗比較高。因為需要動態產生和刪除臨時節點，當集群負載比較高時臨時節點消失會有時間差（一般在一分鍾范圍內）。
redis分布式鎖
redis的分布式鎖實現比zookeeper分布式鎖實現復雜，也分為redis單實例和多實例（master-master）實現方式。
需要特別指出的是redis如果是master-slave這種結構部署時，獲取和釋放鎖都只能向master請求，和單實例的實現原理基本一樣，否則主從切換時會出現多人拿到同一把鎖的情況。
例如：
- 客戶端A在master拿到了鎖。
- master節點在把A創建的key寫入slave之前宕機了。（主從同步是異步操作）
- slave變成了master節點。
- B也得到了和A還持有的相同的鎖，因為slave還沒有A持有鎖的信息。
redis單實例實現方案
通過下面命令獲得鎖：
SET resource_name my_random_value NX PX 30000
這個命令的作用是只有這個key不存在時才會設置這個key的值（NX的作用，即not exist），超時時間設置為30000毫秒（PX的作用），這個key的值設置為my_random_value。這個值必須在所有獲取鎖請求的客戶端里面保持唯一。
key值的超時時間，也叫做“鎖有效時間”。這是鎖的自動釋放時間。
這套實現方案在非分布式的、單點的、保證永不宕機的環境是適用的。
redis集群實現方案（Redlock算法）
在分布式版本的算法里我們假設有N個redis master節點，這些節點完全獨立，不用任何的復制或者分布式協調算法來同步數據。
這里假設N=5，一個客戶端獲取鎖的過程如下：
- 獲取當前以毫秒為單位的時間。
- 輪詢用相同的key在N個節點上面請求鎖。（每個請求的超時時間設置的短一些，為了一個master節點不用時，快速請求下一個master）。
- 如果在超過一半master節點上面成功獲取鎖（這里是3個），客戶端計算第二步請求鎖花費的時間，如果小於鎖釋放時間，則認為獲取鎖成功。
- 如果鎖獲取成功了，那么現在 鎖自動釋放時間=最初鎖釋放時間-請求鎖花費的時間
- 如果獲取鎖失敗了（成功的鎖不超過master數量的一般 或者 請求耗時>鎖釋放時間），那么客戶端都會在每個master節點上面釋放鎖。
獲取鎖成功的節點數需要超過master節點數量的一半才認為是獲取鎖成功的思路應該是借鑒了zookeeper的paxos算法。
還有一個需要指出的點是，當一個客戶端獲取失敗時應該隨時延時后再進行重試，避免多個客戶端同時重試又同時失敗。
優點：性能高
缺點：單實例會有單點問題，多實例主從切換會導致數據丟失，master-master集群模式實現復雜。
參考
redis官方文檔 https://redis.io/topics/distlock