開篇介紹
大家好，我是Java最全面試題庫的提褲姐，今天這篇是JavaEE面試題系列的第十二篇，主要總結了ZooKeeper相關的面試題；在後續，會沿著第一篇開篇的知識線路一直總結下去，做到日更！如果我能做到百日百更，希望你也可以跟著百日百刷，一百天養成一個好習慣。
ZooKeeper是什麼？
ZooKeeper是一個開放原始碼的分散式協調服務，它是叢集的管理者，監視著叢集中各個節點的狀態根據節點提交的反饋進行下一步合理操作。最終，將簡單易用的介面和效能高效、功能穩定的系統提供給使用者。
分散式應用程式可以基於Zookeeper實現諸如資料釋出/訂閱、負載均衡、命名服務、分散式協調/通知、叢集管理、Master選舉、分散式鎖和分散式佇列等功能。
Zookeeper保證瞭如下分散式一致性特性：
- 順序一致性
- 原子性
- 單一檢視
- 可靠性
- 實時性（最終一致性）
客戶端的讀請求可以被叢集中的任意一臺機器處理，如果讀請求在節點上註冊了監聽器，這個監聽器也是由所連線的zookeeper機器來處理。對於寫請求，這些請求會同時發給其他zookeeper機器並且達成一致後，請求才會返回成功。因此，隨著zookeeper的叢集機器增多，讀請求的吞吐會提高但是寫請求的吞吐會下降。
有序性是zookeeper中非常重要的一個特性，所有的更新都是全域性有序的，每個更新都有一個唯一的時間戳，這個時間戳稱為zxid（Zookeeper Transaction Id）。而讀請求只會相對於更新有序，也就是讀請求的返回結果中會帶有這個zookeeper最新的zxid。
ZooKeeper和dubbo的區別？
Zookeeper:
zookeeper用來註冊服務和進行負載均衡，哪一個服務由哪一個機器來提供必需讓呼叫者知道，
簡單來說就是ip地址和服務名稱的對應關係。當然也可以通過硬編碼的方式把這種對應關係在呼叫方業務程式碼中實現，但是如果提供服務的機器掛掉，呼叫者無法知曉，如果不更改程式碼會繼續請求掛掉的機器提供服務。 zookeeper通過心跳機制可以檢測掛掉的機器並將掛掉機器的ip和服務對應關係從列表中刪除。至於支援高併發,簡單來說就是橫向擴充套件,在不更改程式碼的情況通過新增機器來提高運算能力。通過新增新的機器向 zookeeper註冊服務，服務的提供者多了能服務的客戶就多了。
dubbo:
是管理中間層的工具，在業務層到資料倉儲間有非常多服務的接入和服務提供者需要排程，dubbo提供一個框架解決這個問題。
zookeeper和 dubbo的關係：
Dubbo將註冊中心進行抽象，它可以外接不同的儲存媒介給註冊中心提供服務，有 ZooKeeper, Memcached, Redis等。
注意這裡的 dubbo只是一個框架，這個框架中要完成排程必須要有一個分散式的註冊中心，儲存所有服務的後設資料，可以用zk，也可以用別的。
Zookeeper的java客戶端都有哪些?
- zk自帶的 zkclient
- Apache開源的 Curator
ZooKeeper提供了什麼？
- 檔案系統
- 通知機制
說說ZooKeeper檔案系統
Zookeeper提供一個多層級的節點名稱空間(節點稱為 znode)。與檔案系統不同的是，這些節點都可以設定關聯的資料，而檔案系統中只有檔案節點可以存放資料而目錄節點不行。
Zookeeper為了保證高吞吐和低延遲，在記憶體中維護了這個樹狀的目錄結構，這種特性使得 Zookeeper不能用於存放大量的資料,每個節點的存放資料上限為1M。
說說ZAB協議？
ZAB協議是為分散式協調服務Zookeeper專門設計的一種支援崩潰恢復的原子廣播協議。
ZAB協議包括兩種基本的模式：崩潰恢復和訊息廣播。
當整個zookeeper叢集剛剛啟動或者Leader伺服器當機、重啟或者網路故障導致不存在過半的伺服器與Leader伺服器保持正常通訊時，所有程式（伺服器）進入崩潰恢復模式，首先選舉產生新的Leader伺服器，然後叢集中Follower伺服器開始與新的Leader伺服器進行資料同步，當叢集中超過半數機器與該Leader伺服器完成資料同步之後，退出恢復模式進入訊息廣播模式，Leader伺服器開始接收客戶端的事務請求生成事物提案來進行事務請求處理。
Znode有哪些型別
PERSISTENT-持久節點
除非手動刪除，否則節點一直存在於Zookeeper上
EPHEMERAL-臨時節點
臨時節點的生命週期與客戶端會話繫結，一旦客戶端會話失效（客戶端與zookeeper連線斷開不一定會話失效），那麼這個客戶端建立的所有臨時節點都會被移除。
PERSISTENT_SEQUENTIAL-持久順序節點
基本特性同持久節點，只是增加了順序屬性，節點名後邊會追加一個由父節點維護的自增整型數字。
EPHEMERAL_SEQUENTIAL-臨時順序節點
基本特性同臨時節點，增加了順序屬性，節點名後邊會追加一個由父節點維護的自增整型數字。
Zookeeper節點當機如何處理？
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有哪幾種幾種部署模式?
Zookeeper有三種部署模式：
單機部署：一臺叢集上執行叢集部署：多臺叢集執行偽叢集部署：一臺叢集啟動多個 Zookeeper例項執行
Zookeeper的典型應用場景？
Zookeeper是一個典型的釋出/訂閱模式的分散式資料管理與協調框架，開發人員可以使用它來進行分散式資料的釋出和訂閱。
通過對 Zookeeper中豐富的資料節點進行交叉使用，配合 Watcher事件通知機制，可以非常方便的構建一系列分散式應用，會涉及的核心功能：
- 資料釋出/訂閱
- 負載均衡
- 命名服務
- 分散式協調/通知
- 叢集管理
- Master選舉
- 分散式鎖
- 分散式佇列
說一下Zookeeper Watcher機制
Zookeeper允許客戶端向服務端的某個 Znode註冊個 Watcher監聽，當服務端的一些指定事件觸發了這個 Watcher，服務端會向指定客戶端傳送一個事件通知來實現分散式的通知功能，客戶端根據 Watcher通知狀態和事件型別做出業務上的改變。
工作機制：
- 客戶端註冊 watcher
- 服務端處理watcher
- 客戶端回撥 watcher
客戶端註冊Watcher的流程？
1、客戶端註冊Watcher實現
2、呼叫getData()/getChildren()/exist()三個API，傳入Watcher物件
3、標記請求request，封裝Watcher到WatchRegistration
4、封裝成Packet物件，發服務端傳送request
5、收到服務端響應後，將Watcher註冊到ZKWatcherManager中進行管理
6、請求返回，完成註冊。
服務端處理Watcher的流程？
1、服務端接收Watcher並儲存
接收到客戶端請求，處理請求判斷是否需要註冊Watcher，需要的話將資料節點的節點路徑和ServerCnxn（ServerCnxn代表一個客戶端和服務端的連線，實現了Watcher的process介面，此時可以看成一個Watcher物件）儲存在WatcherManager的WatchTable和watch2Paths中去。
2、Watcher觸發
- 以服務端接收到 setData() 事務請求觸發NodeDataChanged事件為例：
- 封裝WatchedEvent
- 將通知狀態（SyncConnected）、事件型別（NodeDataChanged）以及節點路徑封裝成一個WatchedEvent物件
- 查詢Watcher
- 從WatchTable中根據節點路徑查詢Watcher
沒找到；說明沒有客戶端在該資料節點上註冊過Watcher
找到；提取並從WatchTable和Watch2Paths中刪除對應Watcher（從這裡可以看出Watcher在服務端是一次性的，觸發一次就失效了）
3、呼叫process方法來觸發Watcher
這裡process主要就是通過ServerCnxn對應的TCP連線傳送Watcher事件通知。
客戶端回撥 Watcher流程？
1、客戶端SendThread執行緒接收事件通知，交由 EventThread執行緒回撥 Watcher。
2、客戶端的Watcher機制同樣是一次性的，一旦被觸發後，該 Watcher就失效了。
Zookeeper對節點的 watch監聽通知是永久的嗎?為什麼不是永久的?
不是永久的。
官方宣告：一個 Watch事件是一個次性的觸發器，當被設定了 Watch的資料發生了改變的時候，則伺服器將這個改變傳送給設定了 Watch的客戶端，以便通知它們。
原因：
如果服務端變動頻繁，而監聽的客戶端很多情況下，每次變動都要通知到所有的客戶端，給網路和伺服器造成很大壓力。一般是客戶端執行getData（“/節點”，true），如果節點A發生了變更或刪除，客戶端會得到它的 watch事件，但是在之後節點A又發生了變更，而客戶端又沒有設定 watch事件，就不再給客戶端傳送。
在實際應用中，很多情況下，我們的客戶端不需要知道服務端的每一次變動，我只要最新的資料即可。
說說ACL許可權控制機制
1、許可權模式（Scheme）
IP：從IP地址粒度進行許可權控制
Digest：最常用，用類似於 username:password 的許可權標識來進行許可權配置，便於區分不同應用來進行許可權控制
World：最開放的許可權控制方式，是一種特殊的digest模式，只有一個許可權標識“world:anyone”
Super：超級使用者
2、授權物件
授權物件指的是許可權賦予的使用者或一個指定實體，例如IP地址或是機器燈。
3、許可權 Permission
- CREATE：資料節點建立許可權，允許授權物件在該Znode下建立子節點
- DELETE：子節點刪除許可權，允許授權物件刪除該資料節點的子節點
- READ：資料節點的讀取許可權，允許授權物件訪問該資料節點並讀取其資料內容或子節點列表等
- WRITE：資料節點更新許可權，允許授權物件對該資料節點進行更新操作
- ADMIN：資料節點管理許可權，允許授權物件對該資料節點進行ACL相關設定操作
伺服器有哪些角色？
1、Leader
事務請求的唯一排程和處理者，保證叢集事務處理的順序性
叢集內部各服務的排程者
2、Follower
處理客戶端的非事務請求，轉發事務請求給Leader伺服器
參與事務請求Proposal的投票
參與Leader選舉投票
3、Observer
處理客戶端的非事務請求，轉發事務請求給Leader伺服器
不參與任何形式的投票
Zookeeper 下 Server工作狀態有哪些？
1、LOOKING：尋找Leader狀態。當伺服器處於該狀態時，它會認為當前叢集中沒有Leader，因此需要進入Leader選舉狀態。
2、FOLLOWING：跟隨者狀態。表明當前伺服器角色是Follower。
3、LEADING：領導者狀態。表明當前伺服器角色是Leader。
4、OBSERVING：觀察者狀態。表明當前伺服器角色是Observer。
叢集支援動態新增機器嗎？
其實就是水平擴容，Zookeeper在這方面不太好。
兩種方式：
全部重啟：關閉所有 Zookeeper服務，修改配置之後啟動。不影響之前客戶端的會話。逐個重啟：在過半存活即可用的原則下一臺機器重啟不影響整個叢集對外提供服務。（這是比較常用的方式）
3.5版本開始支援動態擴容。
什麼是Chroot？
3.2.0版本後，新增了特性，該特性允許每個客戶端為自己設定一個名稱空間。如果一個客戶端設定了 Chroot，那麼該客戶端對伺服器的任何操作，都將會被限制在其自己的名稱空間下。
通過設定 Chroot，能夠將一個客戶端應用與 Zookeeper服務端的一顆子樹相對應，在那些多個應用公用一個 Zookeeper叢集的場景下，對實現不同應用間的相互隔離非常有幫助。