Java面試題-12Zookeeper

1、ZK節點數據

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

2、Zookeeper 如何保證分佈式數據的一致性特性

Zookeeper 的一些特性和工作原理,包括順序一致性、原子性、單一視圖、可靠性和實時性(最終一致性)。

  1. 順序一致性: Zookeeper 保證所有的更新操作都是全局有序的,每個更新都有一個唯一的時間戳(zxid),並且讀請求的返回結果中會帶有最新的 zxid,確保了更新操作的順序性。

  2. 原子性: 對於寫請求,Zookeeper 會同時將請求發送給其他 Zookeeper 機器,並在達成一致後才返回成功,保證了寫操作的原子性,即要麼全部寫入成功,要麼全部失敗。因此, 隨着 zookeeper 的集羣機器增多,讀請求的吞吐會提高但是寫請求的吞吐會下降。

  3. 單一視圖: Zookeeper 提供了一個單一視圖,即對於所有的客戶端,他們看到的數據都是一致的,這也是 Zookeeper 的可靠性和一致性基礎之一。

  4. 可靠性: Zookeeper 的可靠性體現在其提供了高可用和容錯性,通過集羣機器的增多,可以提高讀請求的吞吐,同時保證寫請求的可靠性和一致性。

  5. 實時性(最終一致性): 對於讀請求,Zookeeper 允許任意一臺機器處理,並且會相對於更新有序,但並不保證實時性,而是保證最終一致性,即數據最終會達到一致狀態。

總體來說,Zookeeper 是一個分佈式協調服務,通過其特性保證了數據的一致性、可靠性和順序性,在分佈式系統中有着廣泛的應用。

 3、zab協議

ZAB(Zookeeper Atomic Broadcast)協議是專門爲分佈式協調服務 Zookeeper 設計的一種支持崩潰恢復的原子廣播協議。它包括兩種基本模式:崩潰恢復和消息廣播。

  1. 崩潰恢復模式: 當整個 Zookeeper 集羣剛啓動、Leader 服務器宕機、重啓或者網絡故障導致不存在過半的服務器與 Leader 服務器保持正常通信時,所有進程(服務器)進入崩潰恢復模式。在該模式下,首先會選舉產生新的 Leader 服務器,然後集羣中的 Follower 服務器開始與新的 Leader 服務器進行數據同步。一旦超過半數的機器與新的 Leader 服務器完成數據同步,集羣就會退出恢復模式,進入消息廣播模式。

  2. 消息廣播模式: 一旦集羣中超過半數的機器與新的 Leader 服務器完成數據同步,集羣就會退出恢復模式進入消息廣播模式。在這個模式下,Leader 服務器開始接收客戶端的事務請求,並生成事務提案來處理這些請求。

ZAB 協議通過這兩種模式,確保了在 Zookeeper 集羣中保持數據的一致性和可靠性。崩潰恢復模式確保在發生故障或初始啓動時,能夠重新選舉 Leader,並進行數據同步;消息廣播模式則確保了在集羣正常運行時,能夠處理客戶端的事務請求並保持數據的一致性。

4、Zookeeper 中節點類型

這些描述是關於 Zookeeper 中節點類型的基本概念,這些節點類型對於分佈式系統中的協調與通知非常重要。

  1. PERSISTENT(持久節點):這種節點在 Zookeeper 上一直存在,除非被手動刪除。即使客戶端會話結束或斷開連接,該節點也不會被刪除。

  2. EPHEMERAL(臨時節點):臨時節點的生命週期與客戶端會話綁定。當創建這樣的節點的客戶端會話失效時(不一定是連接斷開,而是會話失效),這些節點會被自動移除。

  3. PERSISTENT_SEQUENTIAL(持久順序節點):與持久節點類似,但增加了順序屬性。節點名後會追加一個由父節點維護的自增整型數字,以確保節點在創建時按順序排列。

  4. EPHEMERAL_SEQUENTIAL(臨時順序節點):與臨時節點類似,但也增加了順序屬性。節點名後會追加一個由父節點維護的自增整型數字,以確保節點在創建時按順序排列。

這些節點類型在構建分佈式系統時非常有用,例如用於存儲配置信息、服務註冊與發現、分佈式鎖等。通過這些節點類型,可以實現諸如節點監控、任務調度等功能。

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章