ZooKeeper學習總結（3）——ZooKeeper常見面試題
阿新 • • 發佈：2018-12-26
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服務，修改配置之後啟動。不影響之前客戶端的會話。
逐個重啟：顧名思義。這是比較常用的方式。
分散式的、開源的分散式應用程式協調服務，原本是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服務，修改配置之後啟動。不影響之前客戶端的會話。
逐個重啟：顧名思義。這是比較常用的方式。