Zookeeper

前幾天在整理Dubbo的學習心得，因為Zookeeper是Dubbo推薦的註冊中心，所以也安裝部署了一下，看到頭疼推送了《高級Java必問—Zookeeper面試題集錦》，自己試著回答其中幾個問題吧。畢竟還是以開發、Dubbo為主，Zookeeper是個輔助，研究不深，請大家批評指正。

我之前的文章《ZooKeeper單機版安裝配置——集群版後面再發》、《ZooKeeper集群安裝配置使用》

Zookeeper是什麼框架

分散式的、開源的分散式應用程序協調服務，原本是Hadoop、HBase的一個重要組件。它為分散式應用提供一致性服務的軟體，包括：配置維護、域名服務、分散式同步、組服務等。

應用場景

Zookeeper的功能很強大，應用場景很多，結合我實際工作中使用Dubbo框架的情況，Zookeeper主要是做註冊中心用。基於Dubbo框架開發的提供者、消費者都向Zookeeper註冊自己的URL，消費者還能拿到並訂閱提供者的註冊URL，以便在後續程序的執行中去調用提供者。而提供者發生了變動，也會通過Zookeeper向訂閱的消費者發送通知。

Paxos演算法& Zookeeper使用協議

Paxos演算法是分散式選舉演算法，Zookeeper使用的 ZAB協議（Zookeeper原子廣播），二者有相同的地方，比如都有一個Leader，用來協調N個Follower的運行；Leader要等待超半數的Follower做出正確反饋之後才進行提案；二者都有一個值來代表Leader的周期。

不同的地方在於：

ZAB用來構建高可用的分散式數據主備系統（Zookeeper），Paxos是用來構建分散式一致性狀態機系統。

Paxos演算法、ZAB協議要想講清楚可不是一時半會的事兒，自1990年萊斯利·蘭伯特提出Paxos演算法以來，因為晦澀難懂並沒有受到重視。後續幾年，蘭伯特通過好幾篇論文對其進行更進一步地解釋，也直到06年谷歌發表了三篇論文，選擇Paxos作為chubby cell的一致性演算法，Paxos才真正流行起來。

對於普通開發者來說，尤其是學習使用Zookeeper的開發者明確一點就好：分散式Zookeeper選舉Leader伺服器的演算法與Paxos有很深的關係。

選舉演算法和流程

詳情可參看我之前的文章《ZooKeeper集群安裝配置使用》第6節「ZooKeeper選舉機制」，有個簡單的描述。

Zookeeper有哪幾種節點類型

持久：創建之後一直存在，除非有刪除操作，創建節點的客戶端會話失效也不影響此節點。

持久順序：跟持久一樣，就是父節點在創建下一級子節點的時候，記錄每個子節點創建的先後順序，會給每個子節點名加上一個數字後綴。

臨時：創建客戶端會話失效（注意是會話失效，不是連接斷了），節點也就沒了。不能建子節點。

臨時順序：不用解釋了吧。

Zookeeper對節點的watch監聽通知是永久的嗎？

不是。官方聲明：一個Watch事件是一個一次性的觸發器，當被設置了Watch的數據發生了改變的時候，則伺服器將這個改變發送給設置了Watch的客戶端，以便通知它們。

為什麼不是永久的，舉個例子，如果服務端變動頻繁，而監聽的客戶端很多情況下，每次變動都要通知到所有的客戶端，這太消耗性能了。

一般是客戶端執行getData(「/節點A」,true)，如果節點A發生了變更或刪除，客戶端會得到它的watch事件，但是在之後節點A又發生了變更，而客戶端又沒有設置watch事件，就不再給客戶端發送。

在實際應用中，很多情況下，我們的客戶端不需要知道服務端的每一次變動，我只要最新的數據即可。

部署方式？集群中的機器角色都有哪些？集群最少要幾台機器

單機，集群。Leader、Follower。集群最低3（2N+1）台，保證奇數，主要是為了選舉演算法。

集群如果有3台機器，掛掉一台集群還能工作嗎？掛掉兩台呢？

記住一個原則：過半存活即可用。

集群支持動態添加機器嗎？

其實就是水平擴容了，Zookeeper在這方面不太好。兩種方式：

全部重啟：關閉所有Zookeeper服務，修改配置之後啟動。不影響之前客戶端的會話。

逐個重啟：顧名思義。這是比較常用的方式。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！