1、說說?Zookeeper?是什么？

有些軟件你想做成集群或者分布式，你可以用 ZooKeeper 幫你來輔助實現(xiàn)。
特點：ZooKeeper 的特點：維護、協(xié)調、管理、監(jiān)控

最終一致性：客戶端看到的數據最終是一致的。可靠性：服務器保存了消息，那么它就一直都存在。
實時性：ZooKeeper 不能保證兩個客戶端同時得到剛更新的數據。獨立性（等待無關）：不同客戶端直接互不影響。原子性：更新要不成功要不失敗，沒有第三個狀態(tài)。

2、ZooKeeper?有哪些應用場景？

A、數據發(fā)布與訂閱

數據發(fā)布/訂閱的一個常見的場景是配置中心，發(fā)布者把數據發(fā)布到 ZooKeeper 的一個或一系列的

節(jié)點上，供訂閱者進行數據訂閱，達到動態(tài)獲取數據的目的。

配置信息一般有幾個特點:

1. 數據量小的KV?2. 數據內容在運行時會發(fā)生動態(tài)變化3. 集群機器共享，配置一致

ZooKeeper 采用的是推拉結合的方式。

1. 推: 服務端會推給注冊了監(jiān)控節(jié)點的客戶端 Wathcer 事件通知

2. 拉: 客戶端獲得通知后，然后主動到服務端拉取最新的數據

B、命名服務

??作為分布式命名服務，命名服務是指通過指定的名字來獲取資源或者服務的地址，利用ZooKeeper創(chuàng)建一個全局的路徑，這個路徑就可以作為一個名字，指向集群中的集群，提供的服務的地址，或者一個遠程的對象等等。統(tǒng)一命名服務的命名結構圖如下所示：

1、在分布式環(huán)境下，經常需要對應用/服務進行統(tǒng)一命名，便于識別不同服務。類似于域名與IP之間對應關系，IP不容易記住，而域名容易記住。通過名稱來獲取資源或服務的地址，提供者等信息。

2、按照層次結構組織服務/應用名稱?？蓪⒎彰Q以及地址信息寫到ZooKeeper上，客戶端通過ZooKeeper獲取可用服務列表類。

C、集群管理

所謂集群管理就是：是否有機器退出和加入、選舉master。

集群管理主要指集群監(jiān)控和集群控制兩個方面。前者側重于集群運行時的狀態(tài)的收集，后者則是對

集群進行操作與控制。開發(fā)和運維中，面對集群，經常有如下需求:

1. 希望知道集群中究竟有多少機器在工作

2. 對集群中的每臺機器的運行時狀態(tài)進行數據收集

3. 對集群中機器進行上下線的操作

3、說說Zookeeper的工作原理？

Zookeeper的核心是原子廣播，這個機制保證了各個Server之間的同步。實現(xiàn)這個機制的協(xié)議叫做Zab協(xié)議。Zab協(xié)議有兩種模式，它們分別是恢復模式（選主）和廣播模式（同步）。Zab協(xié)議 的全稱是 Zookeeper Atomic Broadcast** （Zookeeper原子廣播）。Zookeeper 是通過Zab 協(xié)議來保證分布式事務的最終一致性。Zab協(xié)議要求每個 Leader 都要經歷三個階段：發(fā)現(xiàn)，同步，廣播。

當服務啟動或者在領導者崩潰后，Zab就進入了恢復模式，當領導者被選舉出來，且大多數Server完成了和 leader的狀態(tài)同步以后，恢復模式就結束了。狀態(tài)同步保證了leader和Server具有相同的系統(tǒng)狀態(tài)。為了保證事務的順序一致性，zookeeper采用了遞增的事務id號（zxid）來標識事務。所有的提議（proposal）都在被提出的時候加 上了zxid。實現(xiàn)中zxid是一個64位的數字，它高32位是epoch用來標識leader關系是否改變，每次一個leader被選出來，它都會有一 個新的epoch，標識當前屬于那個leader的統(tǒng)治時期。低32位用于遞增計數。

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

每個Server在工作過程中有四種狀態(tài)：LOOKING：當前Server不知道leader是誰，正在搜尋。

LEADING：當前Server即為選舉出來的leader。FOLLOWING：leader已經選舉出來，當前Server與之同步。OBSERVING：觀察者狀態(tài)；表明當前服務器角色是 Observer

4、請描述一下?Zookeeper?的通知機制是什么？

Zookeeper 允許客戶端向服務端的某個 znode 注冊一個 Watcher 監(jiān)聽，當服務端的一些指定事件，觸發(fā)了這個 Watcher ，服務端會向指定客戶端發(fā)送一個事件通知來實現(xiàn)分布式的通知功能，然后客戶端根據 Watcher 通知狀態(tài)和事件類型做出業(yè)務上的改變

客戶端注冊 Watcher

1、調用 getData、getChildren、exist 三個 API ，傳入Watcher 對象。

2、標記請求request ，封裝 Watcher 到 WatchRegistration 。

3、封裝成 Packet 對象，發(fā)服務端發(fā)送request 。

4、收到服務端響應后，將 Watcher 注冊到 ZKWatcherManager 中進行管理。

5、請求返回，完成注冊。

服務端處理 Watcher

1、服務端接收 Watcher 并存儲。

2、Watcher 觸發(fā)

3、調用 process 方法來觸發(fā) Watcher 。

客戶端回調 Watcher

1，客戶端 SendThread 線程接收事件通知，交由 EventThread 線程回調Watcher 。

2，客戶端的 Watcher 機制同樣是一次性的，一旦被觸發(fā)后，該 Watcher 就失效了。

5、Zookeeper?對節(jié)點的?watch?監(jiān)聽通知是永久的嗎？

不是一次性的

6、 Zookeeper?集群中有哪些角色？

一個集群中最少需要 3 臺。

Leader事務請求的唯一調度和處理者，保證集群事務處理的I序性。集群內部各服務的調度者。

Follower處理客戶端的非事務請求，轉發(fā)事務請求給 Leader 服務器。參與 Leader 選舉投票，

Observer處理客戶端的非事務請求，轉發(fā)事務請求給 Leader 服務器不參與任何形式的投票。Observer 不需要將事務持久化到磁盤，一旦 Observer 被重啟，需要從 Leader 重新同步整個名字空間.

7、 Zookeeper?是如何保證事務的順序一致性的呢

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

8、 ZooKeeper?集群中個服務器之間是怎樣通信的

Leader 服務器會和每一個 Follower/Observer 服務器都建立 TCP 連接，同時為每個Follower/Observer 都創(chuàng)建一個叫做 LearnerHandler 的實體。LearnerHandler 主要負責 Leader 和Follower/Observer 之間的網絡通訊，包括數據同步，請求轉發(fā)和 proposal 提議的投票等。Leader 服務器保存了所有 Follower/Observer 的 LearnerHandler

9、ZooKeeper 分布式鎖怎么實現(xiàn)的？

如果有客戶端1、客戶端2等N個客戶端爭搶一個 Zookeeper 分布式鎖。大致如下：

1. 大家都是上來直接創(chuàng)建一個鎖節(jié)點下的一個接一個的臨時有序節(jié)點

2. 如果自己不是第一個節(jié)點，就對自己上一個節(jié)點加監(jiān)聽器

3. 只要上一個節(jié)點釋放鎖，自己就排到前面去了，相當于是一個排隊機制。而且用臨時順序節(jié)的

另外一個用意就是，如果某個客戶端創(chuàng)建臨時順序節(jié)點之后，不小心自己宕機了也沒關系，Zookeeper 感知到那個客戶端宕機，會自動刪除對應的臨時順序節(jié)點，相當于自動釋放鎖，或者是自動取消自己的排隊。本地鎖，可以用 JDK 實現(xiàn)，但是分布式鎖就必須要用到分布式的組件。比如 ZooKeeper、Redis。

死鎖問題：鎖不能因為意外就變成死鎖，所以要用 ZK 的臨時節(jié)點，客戶端連接失效了，鎖就自動釋放了。鎖等待問題：鎖有排隊的需求，所以要 ZK 的順序節(jié)點。

鎖管理問題：一個使用釋放了鎖，需要通知其他使用者，所以需要用到監(jiān)聽。

監(jiān)聽的羊群效應：比如有 1000 個鎖競爭者，鎖釋放了，1000 個競爭者就得到了通知，然后判斷，最終序號最小的那個拿到了鎖。其它 999 個競爭者重新注冊監(jiān)聽。這就是羊群效應，出點事，就會驚動整個羊群。應該每個競爭者只監(jiān)聽自己前面的那個節(jié)點。比如 2 號釋放了鎖，那么只有 3 號得到了通知。

10、了解Zookeeper的系統(tǒng)架構嗎？

a) 集群中將選舉出一個leader，其他的機器則稱為follower，所有的寫操作都被傳送給leader，并通過brodcast將所有的更新告訴給follower。

b) 當leader崩潰或者leader失去大多數的follower時，需要重新選舉出一個新的leader，讓所有的服務器都恢復到一個正確的狀態(tài)。

c) 當leader被選舉出來，且大多數服務器完成了 和leader的狀態(tài)同步后，leadder election 的過程就結束了，就將會進入到Atomic brodcast的過程。

d) Atomic Brodcast同步leader和follower之間的信息，保證leader和follower具有形同的系統(tǒng)狀態(tài)。

11、你熟悉Zookeeper節(jié)點ZNode和相關屬性嗎？

Znode兩種類型?：

持久的（persistent）：客戶端和服務器端斷開連接后，創(chuàng)建的節(jié)點不刪除（默認）。

短暫的（ephemeral）：客戶端和服務器端斷開連接后，創(chuàng)建的節(jié)點自己刪除。

Znode有四種形式 ：

1、持久化目錄節(jié)點（PERSISTENT）：客戶端與Zookeeper斷開連接后，該節(jié)點依舊存在

2、持久化順序編號目錄節(jié)點（PERSISTENT_SEQUENTIAL）：客戶端與Zookeeper斷開連接后，該節(jié)點依舊存在，只是Zookeeper給該節(jié)點名稱進行順序編號：

3、臨時目錄節(jié)點（EPHEMERAL）：客戶端與Zookeeper斷開連接后，該節(jié)點被刪除

4、臨時順序編號目錄節(jié)點（EPHEMERAL_SEQUENTIAL）：客戶端與Zookeeper斷開連接后，該節(jié)點被刪除，只是Zookeeper給該節(jié)點名稱進行順序編號

12、Zookeeper選舉中投票信息的五元組是什么？

Leader：被選舉的 Leader 的 SIDZxid：被選舉的 Leader 的事務 ID

Sid：當前服務器的 SIDelectionEpoch：當前投票的輪次peerEpoch：當前服務器的 Epoch

Epoch > Zxid > SidEpoch，Zxid 都可能一致，但是 Sid 一定不一樣，這樣兩張選票一定會 PK 出結果。

13、ZooKeeper?的持久化

數據，存到磁盤或者文件當中。機器重啟后，數據不會丟失。內存 -> 磁盤的映射，和序列化有些像。

napShot 快照，記錄內存中的全量數據，TxnLog 增量事務日志，記錄每一條增刪改記錄（查不是事務日志，不會引起數據變化）