zooKeeper基礎

項目中一直依賴zooKeeper（線上環境是5個節點），這裡對zooKeep最基礎的知識做一個簡單的介紹。

在工作中學習還是以用為主，要多問自己這個工具有什麼用途？能在項目中有什麼應用？

預備知識：

ZooKeeper是一個分散式的應用程序協調服務，是Google的Chubby一個開源的實現。分散式系統的一大難點在於網路是不可靠的。分散式中的節點需要互相通信，如果通信失敗，可能是節點問題，也有可能是網路問題。

如果是同一台機器內多線程的協調，需要學習並發知識；而多台機器之間的協調，則需要學習分散式知識。

一、服務註冊

我們的工程中dubbo強依賴zookeeper，此時的zookeeper是作為服務註冊中心。根據CAP定理，一個分散式系統不可能同時滿足C(一致性)、A(可用性)和P(分區容錯性)。zookeeper滿足的CP。如果zookeeper中的leader節點宕機，會選舉新的leader，此時zookeeper會處於不可用狀態，如果選舉時間太長，會帶來非常糟糕的後果。針對以上問題，Spring Cloud的Eureka的設計就保證了AP，其原理是每個節點是平等的（peer to peer），保證最終一致性。

二、Master選舉

三個Batch Job 部署在三台機器上，但是這三個Batch Job同一個時刻只能有一個運行，如果其中某個不幸down掉，剩下的兩個就需要做個選舉，選出來的那個Batch Job 需要「繼承遺志」，繼續工作。

一個方案是利用資料庫表主鍵不能衝突的特性，讓這三個Batch Job 都向同一個表中插入同樣的數據，誰先成功誰就是Master 。這個方案的漏洞是如果搶到Master的那個Batch Job掛掉了，別人永遠就搶不到了！ 因為記錄已經存在了， 別的Batch Job 沒法插入數據了！補救方案是加入定期更新的機制，master會定期更新狀態，否則會認為master處於下限狀態。

如果使用redis原理與上述方案類似。

如果使用zookeeper，三個Batch Job啟動以後，都去註冊中心爭搶著去創建一個樹的節點（例如/master ），誰創建成功誰就是Master （當然zookeeper必須保證只能創建成功一次，其他請求就失敗了），其他兩個Batch Job就對這個節點虎視眈眈地監控，如果這個節點被刪除，就開始新一輪爭搶，去創建那個/master節點。

使用zookeeper有一個複雜的情況， 如果機器1並沒有死掉，只是和註冊中心長時間連接不上，註冊中心會發現Session超時，會把機器1創建的/master刪除。 讓機器2和機器3去搶，如果機器3成為了master, 開始運行Batch Job, 但是機器1並不知道自己被解除了Master的職務， 還在努力的運行Batch Job，這就衝突了！所以機器1感知到和註冊中心斷開之後，自己要停止任務。

三、分散式鎖

鎖是同步臨界資源（共享資源）的工具，如果是在同一機器內，那麼使用並發機制。如果是多態機器競爭資源，那麼需要分散式鎖。

這些系統在註冊中心的/distribute_lock下都創建子節點， 每個節點都有編號。各個系統去檢查自己的編號，誰的編號小就認為誰持有了鎖， 例如系統1。

系統1持有了鎖，就可以對共享資源進行操作了， 操作完成以後process_01這個節點刪除， 再創建一個新的節點（編號變成process_04了）。

此時系統2持有鎖。如此循環反覆，分散式鎖就實現了。

四、一點原理

關於zookeeper還有其他功能，這裡就此打住，最後說一點zookeeper的內部原理。

1） Session ： 表示某個客戶系統（例如Batch Job）和ZooKeeper之間的連接會話, Batch Job連上ZooKeeper以後會周期性地發送心跳信息， 如果Zookeepr在特定時間內收不到心跳，就會認為這個Batch Job已經死掉了, Session 就會結束。（依賴心跳維持Session）

2）zookeeper的最基礎的數據結構是Znode，在此基礎之上定義了原語（關於數據結構的操作）。按類型可以分為永久的znode（除非主動刪除，否則一直存在），臨時的znode（Session結束就會刪除）和 順序znode（分散式鎖中的process_01,process_02.....）

3.) Watch ： 某個客戶系統（例如Batch Job）可以監控znode， znode節點的變化（刪除，修改數據等）都可以通知Batch Job， 這樣Batch Job可以採取相應的動作，例如爭搶著去創建節點。

參考資料：

什麼是Zookeeper?

ZooKeeper學習第一期---Zookeeper簡單介紹 - sunddenly - 博客園