深入理解Nginx及使用Nginx實現負載均衡，Java崗面試必問
2. ZooKeeper 介紹
2.1. ZooKeeper 由來
正式介紹 ZooKeeper 之前，我們先來看看 ZooKeeper 的由來，還挺有意思的。
下面這段內容摘自《從 Paxos 到 ZooKeeper 》第四章第一節，推薦大家閱讀一下：
ZooKeeper 最早起源於雅虎研究院的一個研究小組。在當時，研究人員發現，在雅虎內部很多大型系統基本都需要依賴一個類似的系統來進行分散式協調，但是這些系統往往都存在分散式單點問題。所以，雅虎的開發人員就試圖開發一個通用的無單點問題的分散式協調框架，以便讓開發人員將精力集中在處理業務邏輯上。
關於“ZooKeeper”這個專案的名字，其實也有一段趣聞。在立項初期，考慮到之前內部很多專案都是使用動物的名字來命名的（例如著名的 Pig 專案),雅虎的工程師希望給這個專案也取一個動物的名字。時任研究院的首席科學家 RaghuRamakrishnan 開玩笑地說：“在這樣下去，我們這兒就變成動物園了！”此話一出，大家紛紛表示就叫動物園管理員吧一一一因為各個以動物命名的分散式元件放在一起，雅虎的整個分散式系統看上去就像一個大型的動物園了，而 ZooKeeper 正好要用來進行分散式環境的協調一一於是，ZooKeeper 的名字也就由此誕生了。
2.2. ZooKeeper 概覽
ZooKeeper 是一個開源的分散式協調服務，它的設計目標是將那些複雜且容易出錯的分散式一致性服務封裝起來，構成一個高效可靠的原語集，並以一系列簡單易用的介面提供給使用者使用。
原語： 作業系統或計算機網路用語範疇。是由若干條指令組成的，用於完成一定功能的一個過程。具有不可分割性·即原語的執行必須是連續的，在執行過程中不允許被中斷。
ZooKeeper 為我們提供了高可用、高效能、穩定的分散式資料一致性解決方案，通常被用於實現諸如資料釋出/訂閱、負載均衡、命名服務、分散式協調/通知、叢集管理、Master 選舉、分散式鎖和分散式佇列等功能。
另外，ZooKeeper 將資料儲存在記憶體中，效能是非常棒的。 在“讀”多於“寫”的應用程式中尤其地高效能，因為“寫”會導致所有的伺服器間同步狀態。（“讀”多於“寫”是協調服務的典型場景）。
2.3. ZooKeeper 特點
- 順序一致性： 從同一客戶端發起的事務請求，最終將會嚴格地按照順序被應用到 ZooKeeper 中去。
- 原子性： 所有事務請求的處理結果在整個叢集中所有機器上的應用情況是一致的，也就是說，要麼整個叢集中所有的機器都成功應用了某一個事務，要麼都沒有應用。
- 單一系統映像 ： 無論客戶端連到哪一個 ZooKeeper 伺服器上，其看到的服務端資料模型都是一致的。
- 可靠性： 一旦一次更改請求被應用，更改的結果就會被持久化，直到被下一次更改覆蓋。
2.4. ZooKeeper 典型應用場景
ZooKeeper 概覽中，我們介紹到使用其通常被用於實現諸如資料釋出/訂閱、負載均衡、命名服務、分散式協調/通知、叢集管理、Master 選舉、分散式鎖和分散式佇列等功能。
下面選 3 個典型的應用場景來專門說說：
- 分散式鎖 ： 通過建立唯一節點獲得分散式鎖，當獲得鎖的一方執行完相關程式碼或者是掛掉之後就釋放鎖。
- 命名服務 ：可以通過 ZooKeeper 的順序節點生成全域性唯一 ID
- 資料釋出/訂閱 ：通過 Watcher 機制 可以很方便地實現資料釋出/訂閱。當你將資料釋出到 ZooKeeper 被監聽的節點上，其他機器可通過監聽 ZooKeeper 上節點的變化來實現配置的動態更新。
實際上，這些功能的實現基本都得益於 ZooKeeper 可以儲存資料的功能，但是 ZooKeeper 不適合儲存大量資料，這一點需要注意。
2.5. 有哪些著名的開源專案用到了 ZooKeeper?
- Kafka : ZooKeeper 主要為 Kafka 提供 Broker 和 Topic 的註冊以及多個 Partition 的負載均衡等功能。
- Hbase : ZooKeeper 為 Hbase 提供確保整個叢集只有一個 Master 以及儲存和提供 regionserver 狀態資訊（是否線上）等功能。
- Hadoop : ZooKeeper 為 Namenode 提供高可用支援。
3. ZooKeeper 重要概念解讀
破音：拿出小本本，下面的內容非常重要哦！
3.1. Data model（資料模型）
ZooKeeper 資料模型採用層次化的多叉樹形結構，每個節點上都可以儲存資料，這些資料可以是數字、字串或者是二級制序列。並且。每個節點還可以擁有 N 個子節點，最上層是根節點以“/”來代表。每個資料節點在 ZooKeeper 中被稱為 znode，它是 ZooKeeper 中資料的最小單元。並且，每個 znode 都一個唯一的路徑標識。
強調一句：ZooKeeper 主要是用來協調服務的，而不是用來儲存業務資料的，所以不要放比較大的資料在 znode 上，ZooKeeper 給出的上限是每個結點的資料大小最大是 1M。
從下圖可以更直觀地看出：ZooKeeper 節點路徑標識方式和 Unix 檔案系統路徑非常相似，都是由一系列使用斜槓"/"進行分割的路徑表示，開發人員可以向這個節點中寫人資料，也可以在節點下面建立子節點。這些操作我們後面都會介紹到。
3.2. znode（資料節點）
介紹了 ZooKeeper 樹形資料模型之後，我們知道每個資料節點在 ZooKeeper 中被稱為 znode，它是 ZooKeeper 中資料的最小單元。你要存放的資料就放在上面，是你使用 ZooKeeper 過程中經常需要接觸到的一個概念。
3.2.1. znode 4種類型
我們通常是將 znode 分為 4 大類：
- 持久（PERSISTENT）節點 ：一旦建立就一直存在即使 ZooKeeper 叢集宕機，直到將其刪除。
- 臨時（EPHEMERAL）節點 ：臨時節點的生命週期是與 客戶端會話（session） 繫結的，會話消失則節點消失 。並且，臨時節點只能做葉子節點 ，不能建立子節點。
- 持久順序（PERSISTENT_SEQUENTIAL）節點 ：除了具有持久（PERSISTENT）節點的特性之外， 子節點的名稱還具有順序性。比如
/node1/app0000000001、/node1/app0000000002。 - 臨時順序（EPHEMERAL_SEQUENTIAL）節點 ：除了具備臨時（EPHEMERAL）節點的特性之外，子節點的名稱還具有順序性。
3.2.2. znode 資料結構
每個 znode 由 2 部分組成:
- stat ：狀態資訊
- data ： 節點存放的資料的具體內容
Java核心架構進階知識點
面試成功其實都是必然發生的事情，因為在此之前我做足了充分的準備工作，不單單是純粹的刷題，更多的還會去刷一些Java核心架構進階知識點，比如：JVM、高併發、多執行緒、快取、Spring相關、分散式、微服務、RPC、網路、設計模式、MQ、Redis、MySQL、設計模式、負載均衡、演算法、資料結構、kafka、ZK、叢集等。而這些也全被整理濃縮到了一份pdf——《Java核心架構進階知識點整理》，全部都是精華中的精華，本著共贏的心態，好東西自然也是要分享的
內容頗多，篇幅卻有限，這就不在過多的介紹了，大家可根據以上截圖自行腦補