前言 關於分散式鎖，在互聯網行業的使用場景還是比較多的，比如電商的庫存扣減，秒殺活動，集群定時任務執行等需要進程互斥的場景。而實現分散式鎖的手段也很多，大家比較常見的就是redis跟zookeeper，今天我們主要介紹的是基於zookeeper實現的分散式鎖。 這篇文章主要借用Curator框架對z ...
前言
關於分散式鎖，在互聯網行業的使用場景還是比較多的，比如電商的庫存扣減，秒殺活動，集群定時任務執行等需要進程互斥的場景。而實現分散式鎖的手段也很多，大家比較常見的就是redis跟zookeeper，今天我們主要介紹的是基於zookeeper實現的分散式鎖。
這篇文章主要借用Curator框架對zk分散式鎖的實現思路，大家理解了以後完全可以自己手動實現一遍，但是在工作中還是建議使用成熟的開源框架，很多坑別人已經幫我們踩好了，除非萬不得已，需要高度定製符合自己項目的需求的時候，才開始自行封裝吧。
正文
zookeeper簡單介紹
既然是基於zookeeper的分散式鎖，首先肯定要對這個zookeeper有一定瞭解，這裡就不過多的進行講解，只對其跟分散式鎖有關聯的特性做一個簡單的介紹，更多詳細的功能特性大家可以參閱官方文檔。
zookeeper維護著類似文件系統的數據結構，它總共有四種類型的節點
-
PERSISTENT：持久化的節點。一旦創建後，即使客戶端與zk斷開了連接，該節點依然存在。
-
PERSISTENT_SEQUENTIAL：持久化順序編號節點。比PERSISTENT節點多了節點自動按照順序編號。
-
EPHEMERAL：臨時節點。當客戶端與zk斷開連接之後，該節點就被刪除。
-
EPHEMERAL_SEQUENTIAL：臨時順序編號節點。比EPHEMERAL節點多了節點自動按照順序編號。（分散式鎖實現使用該節點類型）
Curator實現分散式鎖原理
好，當我們簡單瞭解了zk的節點類型以後，現在正式的分析Curator分散式鎖的實現原理。這裡我們定義了一個“/curator_lock”鎖節點用來存放相關客戶端創建的臨時順序節點。
假設兩個客戶端ClientA跟ClientB同時去爭奪一個鎖，此時ClientA先行一步到達zk，那麼它將會在我們的zk上創建一個“/curator_lock/xxxxx-0000000000”的臨時順序節點。
接著它會獲取到“/curator_lock/”鎖節點下的所有子節點，因為這些節點是有序的，這時候會判斷它所創建的節點是否排在第一位（也就是序號最小），由於ClientA是第一個創建節點的的客戶端，必然是排在第一位，所以它也就拿到了鎖。我們用zkCli查看節點信息如下。
[zk: localhost:2182(CONNECTED) 4] ls /curator_lock [_c_f3f38067-8bff-47ef-9628-e638cfaad77e-lock-0000000000]
這個時候ClientB也來了，按照同樣的步驟，先是在“/curator_lock/”下創建一個臨時順序節點“/curator_lock/xxxxx-0000000001”，這個節點的序號是遞增的，接著也是獲得該節點下的所有子節點，並比對自己當前生成的節點序號是否在這些子節點中是最小的，由於此時序號最小的節點是ClientA創建的，並且還沒釋放掉，所以ClientB自己就拿不到鎖。
[zk: localhost:2182(CONNECTED) 4] ls /curator_lock [_c_2a8198e4-2039-4a3c-8606-39c65790d637-lock-0000000001, _c_f3f38067-8bff-47ef-9628-e638cfaad77e-lock-0000000000]
既然ClientB拿不到鎖，也不會放棄，它會對自己的前一個節點加上監聽器（zk提供的api實現），只要監聽到前一個節點被刪除了，也就是釋放了鎖，就會馬上重新執行獲取鎖的操作。
當後面的ClientC，ClientD...過來的時候也是如此，變化的只是節點上的編號，它會根據Client連接的數量而不斷增加。
可能大家還會擔心，萬一我的獲取到鎖的客戶端宕機了怎麼辦，會不會不釋放鎖？其實上面已經解答了這個問題，由於Curator使用的是臨時順序節點來實現的分散式鎖，只要客戶端與zk連接斷開，該節點也就消失了，相當於釋放了鎖。
下麵代碼展示了Curator的基本使用方法，僅作為參考實例，請勿在生產環境使用的這麼隨意。
CuratorFramework client = CuratorFrameworkFactory.newClient("127.0.0.1:2182",
5000,10000,
new ExponentialBackoffRetry(1000, 3));
client.start();
InterProcessMutex interProcessMutex = new InterProcessMutex(client, "/curator_lock");
//加鎖
interProcessMutex.acquire();
//業務邏輯
//釋放鎖
interProcessMutex.release();
client.close();
總結
我們在搞懂了原理之後，就可以拋棄Curator,自己動手實現一個分散式鎖了，相信有一定經驗的工程師實現基本的功能都是沒問題的，但是要做到生產級別，可能還是要在細節上下功夫，比如說一些異常處理，性能優化等因素要考慮。
該文章首發於微信公眾號《深夜裡的程式猿》，轉載請註明出處，侵權必究。
