【面試題】- ZooKeeper是什么?

ZooKeeper是一個分布式的，開放源碼的分布式 應用程序協調服務 ，是Google的Chubby一個開源的實現， 它是集群的管理者，監視著集群中各個節點的狀態根據節點提交的反饋進行下一步合理操作。最終，將簡單易 用的接口和性能高效、功能穩定的系統提供給用戶。 客戶端的 讀請求 可以被集群中的 任意一臺機器處理 ，如果讀請求在節點上注冊了監聽器，這個監聽器也是由所 連接的zookeeper機器來處理。對于 寫請求 ，這些請求會同 時發給其他 zookeeper 機器并且達成一致后，請 求才會返回成功 。因此，隨著 zookeeper 的集群機器增多，讀請求的吞吐會提高但是寫請求的吞吐會下降 。有序性是zookeeper中非常重要的一個特性，所有的 更新都是全局有序的 ，每個更新都有一個 唯一的時間戳 ， 這個時間戳稱為 zxid ( Zookeeper Transaction Id ) 。而 讀請求只會相對于更新有序 ，也就是讀請求的返回 結果中會帶有這個 zookeeper 最新的 zxid 。

【面試題】- ZooKeeper提供了什么(本質)?

1、文件系統

2、通知機制

【面試題】- Zookeeper文件系統

Zookeeper提供一個多層級的節點命名空間(節點稱為znode)。與文件系統不同的是，這些節點 都可以設置 關聯的數據 ，而文件系統中只有文件節點可以存放數據而目錄節點不行。Zookeeper為了保證高吞吐和低延 遲，在內存中維護了這個樹狀的目錄結構，這種特性使得Zookeeper 不能用于存放大量的數據 ，每個節點的存 放數據上限為 1M 。

【面試題】- 四種類型的znode

1、PERSISTENT- 持久化目錄節點 客戶端與zookeeper斷開連接后，該節點依舊存在

2、PERSISTENT_SEQUENTIAL- 持久化順序編號目錄節點

客戶端與zookeeper斷開連接后，該節點依舊存在，只是Zookeeper給該節點名稱進行順序編號

3、EPHEMERAL- 臨時目錄節點

客戶端與zookeeper斷開連接后，該節點被刪除

4、EPHEMERAL_SEQUENTIAL- 臨時順序編號目錄節點客戶端與zookeeper斷開連接后，該節點被刪除，只是Zookeeper給該節點名稱進行順序編號。

【面試題】- Zookeeper通知機制

client端會對某個znode建立一個watcher 事件 ，當該znode發生變化時，這些client會收到zk的通知， 然后client可以根據znode變化來做出業務上的改變等。

【面試題】- Zookeeper的應用場景?

1、命名服務 2、配置管理 3、集群管理 4、分布式鎖 5、隊列管理

【面試題】- zk的命名服務(文件系統)

命名服務是指通過指定的名字來獲取資源或者服務的地址，利用zk創建一個全局的路徑，即是唯一的路徑，這個路徑就可以作為一個名字，指向集群中的集群，提供的服務的地址，或者一個遠程的對象等等。

【面試題】- Zk的配置管理(文件系統、通知機制)

程序分布式的部署在不同的機器上，將程序的配置信息放在zk的znode 下，當有配置發生改變時，也就是 znode發生變化時，可以通過改變zk中某個目錄節點的內容，利用 watcher 通知給各個客戶端，從而更改配置。

【面試題】- Zookeeper集群管理(文件系統、通知機制)

所謂集群管理無在乎兩點：是否有機器退出和加入、選舉master。對于第一點，所有機器約定在父目錄下創建臨時目錄節點，然后監聽父目錄節點的子節點變化消息。一旦有機器掛掉，該機器與 zookeeper的連接斷開，其所創建的臨時目錄節點被刪除，所有其他機器都收到通知：某個兄弟目錄被刪除，于是，所有人都知道：它上船了。新機器加入也是類似，所有機器收到通知：新兄弟目錄加入，highcount又有了，對于第二點，我們稍微改變 一下，所有機器創建臨時順序編號目錄節點，每次選取編號最小的機器作為 master 就好。

【面試題】- Zookeeper分布式鎖(文件系統、通知機制)

有了zookeeper的一致性文件系統，鎖的問題變得容易。鎖服務可以分為兩類，一個是保持獨占，另一個是控制時序 。 對于第一類，我們將zookeeper上的一個znode看作是一把鎖，通過createznode的方式來實現。所有客戶 端都去創建 /distribute_lock 節點，最終成功創建的那個客戶端也即擁有了這把鎖。用完刪除掉自己創建的 distribute_lock 節點就釋放出鎖。(驚群)

對于第二類， /distribute_lock 已經預先存在，所有客戶端在它下面創建臨時順序編號目錄節點，和選 master一樣， 編號最小的獲得鎖 ，用完刪除，依次方便。

【面試題】 - 作為注冊中心使用，zookeeper和eureka的區別

1、Zookeeper當master掛了，會在30-120s進行leader選舉，這點類似于redis的哨兵機制，在選舉期間Zookeeper是不可用的，這么長時間不能進行服務注冊，是無法忍受的，別說30s，5s都不能忍受。這時Zookeeper集群會癱瘓，這也是Zookeeper的CP，保持節點的一致性，犧牲了A/高可用。

2、而Eureka不會，即使Eureka有部分掛掉，還有其他節點可以使用的，他們保持平級的關系，只不過信息有可能不一致，這就是AP，犧牲了C/一致性。并且Eureka還提供了自我保護機制(15分鐘內超過85%的服務節點沒有心跳/down)，這點我覺得確實要比Zookeeper好，即使服務不可用，也會保留當前失效的微服務，默認90秒，在這90秒Eureka不會注銷微服務，在這90秒內仍然可以接受新的服務注冊，只是不會同步到其他節點上。當壞掉的服務恢復的時候，會自動加入到節點上，也是高可用的一種。然后退出自我保護機制，這也是應對網絡異常的一種機制。

【面試題】- Zookeeper工作原理

Zookeeper的核心是原子廣播，這個機制保證了各個Server之間的同步。實現這個機制的協議叫做Zab協議。Zab協議有兩種模式，它們分別是 恢復模式(選主)和廣播模式(同步)。當服務啟動或者在領導者崩潰后，Zab就進入了恢復模式，當領導者被選舉出來，且大多數Server完成了和leader的狀態同步以后，恢復 模式就結束了。狀態同步保證了leader和Server具有相同的系統狀態。

【面試題】- zookeeper是如何保證事務的順序一致性的?

zookeeper采用了 遞增的事務 Id 來標識，所有的proposal(提議)都在被提出的時候加上了zxid，zxid實際 上是一個64位的數字，高32位是epoch(時期; 紀元; 世; 新時代)用來標識leader是否發生改變，如果有 新的leader產生出來，epoch會自增， 低 32 位用來遞增計數 。當新產生proposal的時候，會依據數據庫的 兩階段過程，首先會向其他的server發出事務執行請求，如果超過半數的機器都能執行并且能夠成功，那么就 會開始執行。

【面試題】- Zookeeper 下 Server工作狀態

每個Server在工作過程中有三種狀態：LOOKING：當前Server不知道leader是誰 ，正在搜尋 LEADING：當前Server即為選舉出來的leader FOLLOWING：leader已經選舉出來，當前Server與之同步。

【面試題】- zookeeper是如何選取主leader的?(zookeeper選舉機制)

當leader崩潰或者leader失去大多數的follower，這時zk進入恢復模式，恢復模式需要重新選舉出一個新的 leader，讓所有的Server都恢復到一個正確的狀態。Zk的選舉算法有兩種：一種是基于basic paxos實現 的，另外一種是基于fast paxos算法實現的。系統默認的選舉算法為 fast paxos 。

1、Zookeeper選主流程(basic paxos)

(1)選舉線程由當前Server發起選舉的線程擔任，其主要功能是對投票結果進行統計，并選出推薦的 Server;

(2)選舉線程首先向所有Server發起一次詢問(包括自己);

(3)選舉線程收到回復后，驗證是否是自己發起的詢問(驗證zxid是否一致)，然后獲取對方的id(myid)，并存 儲到當前詢問對象列表中，最后獲取對方提議的leader相關信息(id,zxid)，并將這些信息存儲到當次選舉的投 票記錄表中;

(4)收到所有Server回復以后，就計算出zxid最大的那個Server，并將這個Server相關信息設置成下一次 要投票的Server;

(5)線程將當前zxid最大的Server設置為當前Server要推薦的Leader，如果此時獲勝的Server獲得n/2 + 1的Server票數，設置當前推薦的leader為獲勝的Server，將根據獲勝的Server相關信息設置自己的狀 態，否則，繼續這個過程，直到leader被選舉出來。 通過流程分析我們可以得出：要使Leader獲得多數 Server的支持，則Server總數必須是奇數2n+1，且存活的Server的數目不得少于n+1. 每個Server啟動后 都會重復以上流程。在恢復模式下，如果是剛從崩潰狀態恢復的或者剛啟動的server還會從磁盤快照中恢復數據和會話信息，zk會記錄事務日志并定期進行快照，方便在恢復時進行狀態恢復。

2、Zookeeper選主流程(fast paxos)

fast paxos流程是在選舉過程中，某Server首先向所有Server提議自己要成為leader，當其它Server收到提 議以后，解決epoch和 zxid的沖突，并接受對方的提議，然后向對方發送接受提議完成的消息，重復這個流程，最后一定能選舉出Leader。

【面試題】- Zookeeper同步流程

選完Leader以后，zk就進入狀態同步過程。

1、Leader等待server連接;

2、Follower連接leader，將最大的zxid發送給leader;

3、Leader根據follower的zxid確定同步點;

4、完成同步后通知follower 已經成為uptodate狀態;

5、Follower收到uptodate消息后，又可以重新接受client的請求進行服務了。

【面試題】- 分布式通知和協調

對于系統調度來說：操作人員發送通知實際是通過控制臺改變某個節點的狀態， 然后zk將這些變化發送給注冊了這個節點的watcher的所有客戶端。對于執行情況匯報：每個工作進程都在某個目錄下創建一個臨時節點。并攜帶工作的進度數據，這樣匯總的進程可以監控目錄子節點的變化獲得工作進度的實時的全局情況 。

【面試題】- 機器中為什么會有leader?

在分布式環境中，有些業務邏輯只需要集群中的某一臺機器進行執行， 其他的機器可以共享這個結果 ，這樣可 以大大 減少重復計算 ， 提高性能 ，于是就需要進行leader選舉。

【面試題】- 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) 。

【面試題】- zookeeper負載均衡和nginx負載均衡區別

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

【面試題】- zookeeper watch機制

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

1、一次性觸發數據發生改變時，一個watcher event會被發送到client，但是client只會收到一次這樣的信息 。

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

3、數據監視Zookeeper有數據監視和子數據監視getdata() and exists()設置數據監視，getchildren()設置了 子節點監視。

4、注冊watcher getData、exists、getChildren。

5、觸發watcher create 、 delete 、 setData。

6、 setData()會觸發znode上設置的data watch(如果set成功的話)。一個成功的 create()操作會觸發被創建的znode上的數據watch，以及其父節點上的child watch。而一個成功的delete() 操作將會同時觸發一個znode的data watch和child watch(因為這樣就沒有子節點了)，同時也會觸發其父節點的child watch。

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

8、Watch是輕量級的，其實就是本地JVM的Callback，服務器端只是存了是否有設置了Watcher的布爾類型。


猜你喜歡：

ZooKeeper視頻教程3天通關

ZooKeeper集群管理

Java高級軟件工程師課程