Zookeeper 面試總結


1:Zookeeper是什么?

  答:ZooKeeper是一個開源的分布式協調服務,是集群的管理者,監視集群節點反饋信息進行下一步合理操作。

  Zookeeper提供的服務:管理用戶程序提交的數據;為用戶程序提供節點監聽服務。

  應用場所:主從協調,服務器節點動態上下線,負載均衡、集群管理等。。。

2:Zookeeper特性:一致性、原子性、單一視圖、可靠性、實時性。

3:Zookeeper集群的角色: Leader 、follower 和 Observer

   Leader:事物請求的唯一調度和處理者,集群內部服務的調度者。

   followe: 參與Leader選舉投票、處理客戶端的非事物請求,轉發事物請求給Leader服務器、參與事物請求Proposal的投票

  Observer:弱化版的Follower,不參與任何投票,主要是為了在不影響集群事務處理能力的前提下提升集群的非事務處理的吞吐量。

4:Zookeeper集群機制的:半數機制:集群中半數以上機器存活,集群可用。

5:Zookeeper提供了文件系統和通知機制

6:Zookeeper協議:ZAB協議,一種支持崩潰恢復的原子廣播協議。

7:四種類型的數據節點-znode

  PERSISTENT-持久節點
  EPHEMERAL-臨時節點
  PERSISTENT_SEQUENTIAL-持久順序節點
  EPHEMERAL_SEQUENTIAL-臨時順序節點

8:zookeeper-watcher-機制----數據變更通知

  Zookeeper允許客戶端向服務端的某個Znode注冊一個Watcher監聽,當服務端的一些指定事件觸發了這個Watcher,服務端會向指定客戶端發送一個事件通知來實現分布式的通知功能,然后客戶端根據Watcher通知狀態和事件類型做出業務上的改變。

  工作機制:客戶端注冊watcher,服務端處理watcher,客戶端回調watcher

 9:Watcher特性總結:一次性、客戶端串行執行、輕量、異步

10:客戶端注冊Watcher實現

  1.調用getData()/getChildren()/exist()三個API,傳入Watcher對象

  2.標記請求request,封裝WatcherWatchRegistration

  3.封裝成Packet對象,發服務端發送request

  4.收到服務端響應后,將Watcher注冊到ZKWatcherManager中進行管理

  5.請求返回,完成注冊。

11:服務端處理Watcher實現

  1.服務端接收Watcher並存儲

  2.Watcher觸發

  3.調用process方法來觸發Watcher

12:客戶端回調Watcher

  客戶端SendThread線程接收事件通知,交由EventThread線程回調Watcher。客戶端的Watcher機制同樣是一次性的,一旦被觸發后,該Watcher就失效了。

13:Zookeeper Server工作狀態

  服務器具有四種狀態,分別是LOOKINGFOLLOWINGLEADINGOBSERVING

  LOOKING:尋找Leader狀態。當服務器處於該狀態時,它會認為當前集群中沒有Leader,因此需要進入Leader選舉狀態。

  FOLLOWING:跟隨者狀態。表明當前服務器角色是Follower

  LEADING:領導者狀態。表明當前服務器角色是Leader

  OBSERVING:觀察者狀態。表明當前服務器角色是Observer

14:Zookeeper的數據同步通常分為四類:

  直接差異化同步(DIFF同步)、先回滾再差異化同步(TRUNC+DIFF同步)、僅回滾同步(TRUNC同步)、全量同步(SNAP同步)

15: zookeeper是如何保證事務的順序一致性的?

  zookeeper采用了全局遞增的事務Id來標識,首先會向其他的server發出事務執行請求,如果超過半數的機器都能執行並且能夠成功,那么就會開始執行。

16:zookeeper負載均衡和nginx負載均衡區別

  zk的負載均衡是可以調控,nginx只是能調權重,其他需要可控的都需要自己寫插件;但是nginx的吞吐量比zk大很多,應該說按業務選擇用哪種方式。

17:Zookeeper允許客戶端向服務端的某個Znode注冊一個Watcher監聽,當服務端的一些指定事件觸發了這個Watcher,服務端會向指定客戶端發送一個事件通知來實現分布式的通知功能,然后客戶端根據Watcher通知狀態和事件類型做出業務上的改變。

18:Watcher特性總結:

  1. 一次性,無論是服務端還是客戶端,一旦一個Watcher被觸發,Zookeeper都會將其從相應的存儲中移除。這樣的設計有效的減輕了服務端的壓力,不然對於更新非常頻繁的節點,服務端會不斷的向客戶端發送事件通知,無論對於網絡還是服務端的壓力都非常大。

  2.客戶端串行執行,客戶端Watcher回調的過程是一個串行同步的過程。

  3.輕量,Watcher通知非常簡單,只會告訴客戶端發生了事件,而不會說明事件的具體內容。客戶端向服務端注冊Watcher的時候,並不會把客戶端真實的Watcher對象實體傳遞到服務端,僅僅是在客戶端請求中使用boolean類型屬性進行了標記。

  4.watcher event異步發送watcher的通知事件從server發送到client是異步的,這就存在一個問題,不同的客戶端和服務器之間通過socket進行通信,由於網絡延遲或其他因素導致客戶端在不通的時刻監聽到事件,由於Zookeeper本身提供了ordering guarantee,即客戶端監聽事件后,才會感知它所監視znode發生了變化。所以我們使用Zookeeper不能期望能夠監控到節點每次的變化。Zookeeper只能保證最終的一致性,而無法保證強一致性。

  5.注冊watcher getDataexistsgetChildren

  6. 觸發watcher createdeletesetData

  7.當一個客戶端連接到一個新的服務器上時,watch將會被以任意會話事件觸發。當與一個服務器失去連接的時候,是無法接收到watch的。而當client重新連接時,如果需要的話,所有先前注冊過的watch,都會被重新注冊。通常這是完全透明的。只有在一個特殊情況下,watch可能會丟失:對於一個未創建的znodeexist watch,如果在客戶端斷開連接期間被創建了,並且隨后在客戶端連接上之前又刪除了,這種情況下,這個watch事件可能會被丟失。

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM