Zookeeper是一個開源的分布式協調服務，由雅虎公司創建，由於最初雅虎公司的內部研究小組的項目大多以動物的名字命名，所以后來就以Zookeeper(動物管理員)來命名了，而就是由Zookeeper來負責這些分布式組件環境的協調工作。
他的目標是可以提供高性能、高可用和順序訪問控制的能力，同時也是為了解決分布式環境下數據一致性的問題。
集群
通常這樣設置的話，是為了避免太多的從節點參與過半寫的過程，導致影響性能，這樣Zookeeper只要使用一個幾台機器的小集群就可以實現高性能了，如果要橫向擴展的話，只需要增加Observer節點即可。
Zookeeper建議集群節點個數為奇數，只要超過一半的機器能夠正常提供服務，那么整個集群都是可用的狀態。
數據節點Znode
Zookeeper中數據存儲於內存之中，這個數據節點就叫做Znode，他是一個樹形結構，比如/a/b/c類似。
而Znode又分為持久節點、臨時節點、順序節點三大類。
持久節點是指只要被創建，除非主動移除，否則都應該一直保存在Zookeeper中。
臨時節點不同的是，他的生命周期和客戶端Session會話一樣，會話失效，那么臨時節點就會被移除。
還有就是臨時順序節點和持久順序節點，除了基本的特性之外，子節點的名稱還具有有序性。
會話Session
會話自然就是指Zookeeper客戶端和服務端之間的通信，他們使用TCP長連接的方式保持通信，通常，肯定會有心跳檢測的機制，同時他可以接受來自服務器的Watch事件通知。
事件監聽器Wather
用戶可以在指定的節點上注冊Wather，這樣在事件觸發的時候，客戶端就會收到來自服務端的通知。
權限控制ACL
Zookeeper使用ACL來進行權限的控制，包含以下5種：
-
CREATE，創建子節點權限
-
DELETE，刪除子節點權限
-
READ，獲取節點數據和子節點列表權限
-
WRITE，更新節點權限
-
ADMIN，設置節點ACL權限
所以，Zookeeper通過集群的方式來做到高可用，通過內存數據節點Znode來達到高性能，但是存儲的數據量不能太大，通常適用於讀多寫少的場景。
Zookeeper有哪些應用場景？
-
命名服務Name Service，依賴Zookeeper可以生成全局唯一的節點ID，來對分布式系統中的資源進行管理。
-
分布式協調，這是Zookeeper的核心使用了。利用Wather的監聽機制，一個系統的某個節點狀態發生改變，另外系統可以得到通知。
-
集群管理，分布式集群中狀態的監控和管理，使用Zookeeper來存儲。
-
Master選舉，利用Zookeeper節點的全局唯一性，同時只有一個客戶端能夠創建成功的特點，可以作為Master選舉使用，創建成功的則作為Master。
-
分布式鎖，利用Zookeeper創建臨時順序節點的特性。
說說Wather監聽機制和它的原理？
Zookeeper可以提供分布式數據的發布/訂閱功能，依賴的就是Wather監聽機制。
客戶端可以向服務端注冊Wather監聽，服務端的指定事件觸發之后，就會向客戶端發送一個事件通知。
他有幾個特性：
-
一次性：一旦一個Wather觸發之后，Zookeeper就會將它從存儲中移除
-
客戶端串行：客戶端的Wather回調處理是串行同步的過程，不要因為一個Wather的邏輯阻塞整個客戶端
-
輕量：Wather通知的單位是WathedEvent，只包含通知狀態、事件類型和節點路徑，不包含具體的事件內容，具體的時間內容需要客戶端主動去重新獲取數據
主要流程如下：
-
客戶端向服務端注冊Wather監聽
-
保存Wather對象到客戶端本地的WatherManager中
-
服務端Wather事件觸發后，客戶端收到服務端通知，從WatherManager中取出對應Wather對象執行回調邏輯
Zookeeper是如何保證數據一致性的？
Zookeeper通過ZAB原子廣播協議來實現數據的最終順序一致性，他是一個類似2PC兩階段提交的過程。
由於Zookeeper只有Leader節點可以寫入數據，如果是其他節點收到寫入數據的請求，則會將之轉發給Leader節點。
主要流程如下：
-
Leader收到請求之后，將它轉換為一個proposal提議，並且為每個提議分配一個全局唯一遞增的事務ID：zxid，然后把提議放入到一個FIFO的隊列中，按照FIFO的策略發送給所有的Follower
-
Follower收到提議之后，以事務日志的形式寫入到本地磁盤中，寫入成功后返回ACK給Leader
-
Leader在收到超過半數的Follower的ACK之后，即可認為數據寫入成功，就會發送commit命令給Follower告訴他們可以提交proposal了
ZAB包含兩種基本模式，崩潰恢復和消息廣播。
整個集群服務在啟動、網絡中斷或者重啟等異常情況的時候，首先會進入到崩潰恢復狀態，此時會通過選舉產生Leader節點，當集群過半的節點都和Leader狀態同步之后，ZAB就會退出恢復模式。之后，就會進入消息廣播的模式。
那么，Zookeeper如何進行Leader選舉的？
Leader的選舉可以分為兩個方面，同時選舉主要包含事務zxid和myid，節點主要包含LEADING\FOLLOWING\LOOKING3個狀態。
-
服務啟動期間的選舉
-
服務運行期間的選舉
服務啟動期間的選舉
-
首先，每個節點都會對自己進行投票，然后把投票信息廣播給集群中的其他節點
-
節點接收到其他節點的投票信息，然后和自己的投票進行比較，首先zxid較大的優先，如果zxid相同那么則會去選擇myid更大者，此時大家都是LOOKING的狀態
-
投票完成之后，開始統計投票信息，如果集群中過半的機器都選擇了某個節點機器作為leader，那么選舉結束
-
最后，更新各個節點的狀態，leader改為LEADING狀態，follower改為FOLLOWING狀態
服務運行期間的選舉
如果開始選舉出來的leader節點宕機了，那么運行期間就會重新進行leader的選舉。
-
leader宕機之后，非observer節點都會把自己的狀態修改為LOOKING狀態，然后重新進入選舉流程
-
生成投票信息(myid,zxid)，同樣，第一輪的投票大家都會把票投給自己，然后把投票信息廣播出去
-
接下來的流程和上面的選舉是一樣的，都會優先以zxid，然后選擇myid，最后統計投票信息，修改節點狀態，選舉結束
那選舉之后又是怎樣進行數據同步的？
那實際上Zookeeper在選舉之后，Follower和Observer（統稱為Learner）就會去向Leader注冊，然后就會開始數據同步的過程。
數據同步包含3個主要值和4種形式。
PeerLastZxid：Learner服務器最后處理的ZXID
minCommittedLog：Leader提議緩存隊列中最小ZXID
maxCommittedLog：Leader提議緩存隊列中最大ZXID
直接差異化同步 DIFF同步
如果PeerLastZxid在minCommittedLog和maxCommittedLog之間，那么則說明Learner服務器還沒有完全同步最新的數據。
-
首先Leader向Learner發送DIFF指令，代表開始差異化同步，然后把差異數據（從PeerLastZxid到maxCommittedLog之間的數據）提議proposal發送給Learner
-
發送完成之后發送一個NEWLEADER命令給Learner，同時Learner返回ACK表示已經完成了同步
-
接着等待集群中過半的Learner響應了ACK之后，就發送一個UPTODATE命令，Learner返回ACK，同步流程結束
先回滾再差異化同步 TRUNC+DIFF同步
這個設置針對的是一個異常的場景。
如果Leader剛生成一個proposal，還沒有來得及發送出去，此時Leader宕機，重新選舉之后作為Follower，但是新的Leader沒有這個proposal數據。
舉個栗子：
假設現在的Leader是A，minCommittedLog=1，maxCommittedLog=3，剛好生成的一個proposal的ZXID=4，然后掛了。
重新選舉出來的Leader是B，B之后又處理了2個提議，然后minCommittedLog=1，maxCommittedLog=5。
這時候A的PeerLastZxid=4，在(1,5)之間。
那么這一條只存在於A的提議怎么處理？
A要進行事務回滾，相當於拋棄這條數據，並且回滾到最接近於PeerLastZxid的事務，對於A來說，也就是PeerLastZxid=3。
流程和DIFF一致，只是會先發送一個TRUNC命令，然后再執行差異化DIFF同步。
僅回滾同步 TRUNC同步
針對PeerLastZxid大於maxCommittedLog的場景，流程和上述一致，事務將會被回滾到maxCommittedLog的記錄。
這個其實就更簡單了，也就是你可以認為TRUNC+DIFF中的例子，新的Leader B沒有處理提議，所以B中minCommittedLog=1，maxCommittedLog=3。
所以A的PeerLastZxid=4就會大於maxCommittedLog了，也就是A只需要回滾就行了，不需要執行差異化同步DIFF了。
全量同步 SNAP同步
適用於兩個場景：
-
PeerLastZxid小於minCommittedLog
-
Leader服務器上沒有提議緩存隊列，並且PeerLastZxid不等於Leader的最大ZXID
這兩種場景下，Leader將會發送SNAP命令，把全量的數據都發送給Learner進行同步。
有可能會出現數據不一致的問題嗎？
還是會存在的，我們可以分成3個場景來描述這個問題。
查詢不一致
因為Zookeeper是過半成功即代表成功，假設我們有5個節點，如果123節點寫入成功，如果這時候請求訪問到4或者5節點，那么有可能讀取不到數據，因為可能數據還沒有同步到4、5節點中，也可以認為這算是數據不一致的問題。
解決方案可以在讀取前使用sync命令。
leader未發送proposal宕機
這也就是數據同步說過的問題。
leader剛生成一個proposal，還沒有來得及發送出去，此時leader宕機，重新選舉之后作為follower，但是新的leader沒有這個proposal。
這種場景下的日志將會被丟棄。
leader發送proposal成功，發送commit前宕機
如果發送proposal成功了，但是在將要發送commit命令前宕機了，如果重新進行選舉，還是會選擇zxid最大的節點作為leader，因此，這個日志並不會被丟棄，會在選舉出leader之后重新同步到其他節點當中。
如果作為注冊中心，Zookeeper 和Eureka、Consul、Nacos有什么區別？
| Nacos | Eureka | Consul | Zookeeper | |
|---|---|---|---|---|
| 一致性協議 | CP+AP | AP | CP | CP |
| 健康檢查 | TCP/HTTP/MYSQL/Client Beat | Client Beat | TCP/HTTP/gRPC/Cmd | Keep Alive |
| 負載均衡策略 | 權重/ metadata/Selector | Ribbon | Fabio | — |
| 雪崩保護 | 有 | 有 | 無 | 無 |
| 自動注銷實例 | 支持 | 支持 | 不支持 | 支持 |
| 訪問協議 | HTTP/DNS | HTTP | HTTP/DNS | TCP |
| 監聽支持 | 支持 | 支持 | 支持 | 支持 |
| 多數據中心 | 支持 | 支持 | 支持 | 不支持 |
| 跨注冊中心同步 | 支持 | 不支持 | 支持 | 不支持 |
| SpringCloud集成 | 支持 | 支持 | 支持 | 不支持 |
| Dubbo集成 | 支持 | 不支持 | 不支持 | 支持 |
| K8S集成 | 支持 | 不支持 | 支持 | 不支持 |
最后，你對於CAP理論怎么理解？
CAP是一個分布式系統設計的定理，他包含3個部分，並且最多只能同時滿足其中兩個。
-
Consistency一致性，因為在一個分布式系統中，數據肯定需要在不同的節點之間進行同步，就比如Zookeeper，所以一致性就是指的是數據在不同的節點之間怎樣保證一致性，對於純理論的C而言，默認的規則是忽略掉延遲的，因為如果考慮延遲的話，因為數據同步的過程無論如何都會有延遲的，延遲的過程必然會帶來數據的不一致。
-
Availability可用性，這個指的是對於每一個請求，節點總是可以在合理的時間返回合理的響應，比如Zookeeper在進行數據同步時，無法對外提供讀寫服務，不滿足可用性要求。這里常有的一個例子是說Zookeeper選舉期間無法提供服務不滿足A，這個說法並不准確，因為CAP關注的是數據的讀寫，選舉可以認為不在考慮范圍之內。所以，可以認為對於數據的讀寫，無論響應超時還是返回異常都可以認為是不滿足A。
-
Partition-tolerance分區容錯性，因為在一個分布式系統當中，很有可能由於部分節點的網絡問題導致整個集群之間的網絡不連通，所以就產生了網絡分區，整個集群的環境被分隔成不同的的子網，所以，一般說網絡不可能100%的不產生問題，所以P一定會存在。
為什么只能同時滿足CAP中的兩個呢？
以A\B兩個節點同步數據舉例，由於P的存在，那么可能AB同步數據出現問題。
如果選擇AP，由於A的數據未能正確同步到B，所以AB數據不一致，無法滿足C。
如果選擇CP，那么B就不能提供服務，就無法滿足A。
巨人的肩膀：
https://my.oschina.net/yunqi/blog/3040280
《從Paxos到Zookeeper分布式一致性原理與實踐》