好程序員Java教程之ZooKeeper面試題梳理彙總，隨着疫情的好轉，各大企業開始以遠程面試的形式進行人才招聘，而Java行業依舊是需求量最大的人羣，但招聘要求卻有很大提高。有學員擔心無法通過企業面試，其實只要你技能過關、表現良好，高薪就不是問題。接下來的好程序員Java就業指導小編就給大家分享ZooKeeper相關的面試題。
ZooKeeper是什麼?
ZooKeeper是一個開放源碼的分佈式協調服務，它是集羣的管理者，監視着集羣中各個節點的狀態根據節點提交的反饋進行下一步合理操作。最終，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶。
分佈式應用程序可以基於Zookeeper實現諸如數據發佈/訂閱、負載均衡、命名服務、分佈式協調/通知、集羣管理、Master選舉、分佈式鎖和分佈式隊列等功能。Zookeeper保證分佈式一致性特性：順序一致性、原子性、單一視圖、可靠性、實時性(最終一致性)。
ZooKeeper負載均衡和nginx負載均衡區別
ZooKeeper
1)不存在單點問題，zab機制保證單點故障可重新選舉一個leader;
2)只負責服務的註冊與發現，不負責轉發，減少一次數據交換(消費方與服務方直接通信);
3)需要自己實現相應的負載均衡算法。
nginx
1))存在單點問題，單點負載高數據量大,需要通過KeepAlived+LVS備機實現高可用;
2)每次負載，都充當一次中間人轉發角色，增加網絡負載量(消費方與服務方間接通信);
3)自帶負載均衡算法。
Zookeeper Watcher 機制--數據變更通知
Zookeeper允許客戶端向服務端的某個Znode註冊一個Watcher監聽，當服務端的一些指定事件觸發了這個Watcher，服務端會向指定客戶端發送一個事件通知來實現分佈式的通知功能，然後客戶端根據Watcher通知狀態和事件類型做出業務上的改變。
工作機制：
客戶端註冊watcher
服務端處理watcher
客戶端回調watcher
ZooKeeper是如何保證事務的順序一致性的?
ZooKeeper採用了全局遞增的事務Id來標識，所有的proposal(提議)都在被提出的時候加上了zxid，zxid實際上是一個64位的數字，高32位是epoch(時期; 紀元; 世; 新時代)用來標識leader週期，如果有新的leader產生出來，epoch會自增，低32位用來遞增計數。當新產生proposal的時候，會依據數據庫的兩階段過程，首先會向其他的server發出事務執行請求，如果超過半數的機器都能執行並且能夠成功，那麼就會開始執行。
Zookeeper對節點的watch監聽通知是永久的嗎?
不是。官方聲明：一個Watch事件是一個一次性的觸發器，當被設置了Watch的數據發生了改變的時候，則服務器將這個改變發送給設置了Watch的客戶端，以便通知它們。
爲什麼不是永久的，舉個例子，如果服務端變動頻繁，而監聽的客戶端很多情況下，每次變動都要通知到所有的客戶端，給網絡和服務器造成很大壓力。
一般是客戶端執行getData(“/節點A”,true)，如果節點A發生了變更或刪除，客戶端會得到它的watch事件，但是在之後節點A又發生了變更，而客戶端又沒有設置watch事件，就不再給客戶端發送。
在實際應用中，很多情況下，我們的客戶端不需要知道服務端的每一次變動，我只要最新的數據即可。
ZK節點宕機如何處理?
Zookeeper本身也是集羣，推薦配置不少於3個服務器。Zookeeper自身也要保證當一個節點宕機時，其他節點會繼續提供服務。
如果是一個Follower宕機，還有2臺服務器提供訪問，因爲Zookeeper上的數據是有多個副本的，數據並不會丟失;
如果是一個Leader宕機，Zookeeper會選舉出新的Leader。
ZK集羣的機制是隻要超過半數的節點正常，集羣就能正常提供服務。只有在ZK節點掛得太多，只剩一半或不到一半節點能工作，集羣才失效。
所以：
3個節點的cluster可以掛掉1個節點(leader可以得到2票>1.5);
2個節點的cluster就不能掛掉任何1個節點了(leader可以得到1票<=1)。