java關鍵字列表，Java開發面試題

ZooKeeper是一個分散式的，開放原始碼的分散式應用程式協調服務，是Google的Chubby一個開源的實現（Chubby是不開源的），它是叢集的管理者，監視著叢集中各個節點的狀態根據節點提交的反饋進行下一步合理操作。最終，將簡單易用的介面和效能高效、功能穩定的系統提供給使用者 。

Zookeeper一個最常用的使用場景就是用於擔任服務生產者和服務消費者的註冊中心，服務生產者將自己提供的服務註冊到Zookeeper中心，服務的消費者在進行服務呼叫的時候先到Zookeeper中查，獲取到服務生產者的詳細資訊之後，再去呼叫服務生產者的內容與資料，簡單示例圖如下：

NO2：瞭解Zookeeper的系統架構嗎？

ZooKeeper 的架構圖中我們需要了解和掌握的主要有：

（1）ZooKeeper分為伺服器端（Server） 和客戶端（Client），客戶端可以連線到整個 ZooKeeper服務的任意伺服器上（除非 leaderServes 引數被顯式設定， leader 不允許接受客戶端連線）。

（2）客戶端使用並維護一個 TCP 連線，透過這個連線傳送請求、接受響應、獲取觀察的事件以及傳送資訊。如果這個 TCP 連線中斷，客戶端將自動嘗試連線到另外的 ZooKeeper伺服器。客戶端第一次連線到 ZooKeeper服務時，可以接受這個連線的 ZooKeeper伺服器會為這個客戶端建立一個會話。當這個客戶端連線到另外的伺服器時，這個會話會被新的伺服器重新建立。

（3）上圖中每一個Server代表一個安裝Zookeeper服務的機器，即是整個提供Zookeeper服務的叢集（或者是由偽叢集組成）；

（4）組成ZooKeeper服務的伺服器必須彼此瞭解。它們維護一個記憶體中的狀態影像，以及持久儲存中的事務日誌和快照， 只要大多數伺服器可用，ZooKeeper服務就可用；

（5）ZooKeeper 啟動時，將從例項中選舉一個 leader，Leader 負責處理資料更新等操作，一個更新操作成功的標誌是當且僅當大多數Server在記憶體中成功修改資料。每個Server 在記憶體中儲存了一份資料。

（6）Zookeeper是可以叢集複製的，叢集間透過Zab協議（Zookeeper Atomic Broadcast）來保持資料的一致性；

（7）Zab協議包含兩個階段：leader election階段和Atomic Brodcast階段。

a) 叢集中將選舉出一個leader，其他的機器則稱為follower，所有的寫操作都被傳送給leader，並透過brodcast將所有的更新告訴給follower。
b) 當leader崩潰或者leader失去大多數的follower時，需要重新選舉出一個新的leader，讓所有的伺服器都恢復到一個正確的狀態。
c) 當leader被選舉出來，且大多數伺服器完成了 和leader的狀態同步後，leadder election 的過程就結束了，就將會進入到Atomic brodcast的過程。
d) Atomic Brodcast同步leader和follower之間的資訊，保證leader和follower具有形同的系統狀態。
NO3：能說說Zookeeper的工作原理？
Zookeeper的核心是原子廣播，這個機制保證了各個Server之間的同步。實現這個機制的協議叫做Zab協議。

Zab協議有兩種模式，它們 分別是恢復模式（選主）和廣播模式（同步）。

Zab協議 的全稱是 Zookeeper Atomic Broadcast** （Zookeeper原子廣播）。Zookeeper 是透過 Zab 協議來保證分散式事務的最終一致性。Zab協議要求每個 Leader 都要經歷三個階段：發現，同步，廣播。

當服務啟動或者在領導者崩潰後，Zab就進入了恢復模式，當領導者被選舉出來，且大多數Server完成了和 leader的狀態同步以後，恢復模式就結束了。狀態同步保證了leader和Server具有相同的系統狀態。

為了保證事務的順序一致性，zookeeper採用了遞增的事務id號（zxid）來標識事務。所有的提議（proposal）都在被提出的時候加 上了zxid。實現中zxid是一個64位的數字，它高32位是epoch用來標識leader關係是否改變，每次一個leader被選出來，它都會有一 個新的epoch，標識當前屬於那個leader的統治時期。第32位用於遞增計數。

epoch：可以理解為皇帝的年號，當新的皇帝leader產生後，將有一個新的epoch年號。

每個Server在工作過程中有三種狀態：

LOOKING：當前Server不知道leader是誰，正在搜尋。
LEADING：當前Server即為選舉出來的leader。
FOLLOWING：leader已經選舉出來，當前Server與之同步。
NO4：Zookeeper為什麼要這麼設計？
ZooKeeper設計的目的是提供高效能、高可用、順序一致性的分散式協調服務、保證資料最終一致性。

高效能（簡單的資料模型）

採用樹形結構組織資料節點；
全量資料節點，都儲存在記憶體中；
Follower 和 Observer 直接處理非事務請求；
高可用（構建叢集）

半數以上機器存活，服務就能正常執行
自動進行 Leader 選舉
順序一致性（事務操作的順序）

每個事務請求，都會轉發給 Leader 處理
每個事務，會分配全域性唯一的遞增id（zxid，64位：epoch + 自增 id）
最終一致性

透過提議投票方式，保證事務提交的可靠性
提議投票方式，只能保證 Client 收到事務提交成功後，半數以上節點能夠看到最新資料
NO5：你知道Zookeeper中有哪些角色？
系統模型：

領導者（leader）

Leader伺服器為客戶端提供讀服務和寫服務。負責進行投票的發起和決議，更新系統狀態。

學習者（learner）

跟隨者（follower） Follower伺服器為客戶端提供讀服務，參與Leader選舉過程，參與寫操作“過半寫成功”策略。
觀察者（observer） Observer伺服器為客戶端提供讀服務，不參與Leader選舉過程，不參與寫操作“過半寫成功”策略。用於在不影響寫效能的前提下提升叢集的讀效能。
客戶端（client）：服務請求發起方。

NO6：你熟悉Zookeeper節點ZNode和相關屬性嗎？
節點有哪些型別？

Znode兩種型別：

持久的（persistent）：客戶端和伺服器端斷開連線後，建立的節點不刪除（預設）。

短暫的（ephemeral）：客戶端和伺服器端斷開連線後，建立的節點自己刪除。

Znode有四種形式：

持久化目錄節點（PERSISTENT）：客戶端與Zookeeper斷開連線後，該節點依舊存在持久化順序編號目錄節點（PERSISTENT_SEQUENTIAL）
客戶端與Zookeeper斷開連線後，該節點依舊存在，只是Zookeeper給該節點名稱進行順序編號：臨時目錄節點（EPHEMERAL）
客戶端與Zookeeper斷開連線後，該節點被刪除：臨時順序編號目錄節點（EPHEMERAL_SEQUENTIAL）
客戶端與Zookeeper斷開連線後，該節點被刪除，只是Zookeeper給該節點名稱進行順序編號
「注意」：建立ZNode時設定順序標識，ZNode名稱後會附加一個值，順序號是一個單調遞增的計數器，由父節點維護。

版權宣告：本文為原創文章，轉載請附上原文出處連結及本宣告。下載相關影片學習資料到尚矽谷官方網站。