29道Zookeeper面試題超詳細(附答案)
原文連結
ZooKeeper是一個分散式的，開放原始碼的分散式應用程式協調服務，是Google的Chubby一個開源的實現，是Hadoop和Hbase的重要元件。它是一個為分散式應用提供一致性服務的軟體，提供的功能包括：配置維護、域名服務、分散式同步、組服務等。
在分散式領域，Zookeeper的身影出現的越來越頻繁。以下整理了Zookeeper的29道面試題，附答案，如有不恰當之處歡迎留言指正。
1. ZooKeeper是什麼？
ZooKeeper是一個開放原始碼的分散式協調服務，它是叢集的管理者，監視著叢集中各個節點的狀態根據節點提交的反饋進行下一步合理操作。最終，將簡單易用的介面和效能高效、功能穩定的系統提供給使用者。
分散式應用程式可以基於Zookeeper實現諸如資料釋出/訂閱、負載均衡、命名服務、分散式協調/通知、叢集管理、Master選舉、分散式鎖和分散式佇列等功能。
Zookeeper保證瞭如下分散式一致性特性：
- 順序一致性
- 原子性
- 單一檢視
- 可靠性
- 實時性（最終一致性）
客戶端的讀請求可以被叢集中的任意一臺機器處理，如果讀請求在節點上註冊了監聽器，這個監聽器也是由所連線的zookeeper機器來處理。對於寫請求，這些請求會同時發給其他zookeeper機器並且達成一致後，請求才會返回成功。因此，隨著zookeeper的叢集機器增多，讀請求的吞吐會提高但是寫請求的吞吐會下降。
有序性是zookeeper中非常重要的一個特性，所有的更新都是全域性有序的，每個更新都有一個唯一的時間戳，這個時間戳稱為zxid（Zookeeper Transaction Id）。而讀請求只會相對於更新有序，也就是讀請求的返回結果中會帶有這個zookeeper最新的zxid。
2. ZooKeeper提供了什麼？
1、檔案系統
2、通知機制
3. Zookeeper檔案系統
Zookeeper提供一個多層級的節點名稱空間（節點稱為znode）。與檔案系統不同的是，這些節點都可以設定關聯的資料，而檔案系統中只有檔案節點可以存放資料而目錄節點不行。
Zookeeper為了保證高吞吐和低延遲，在記憶體中維護了這個樹狀的目錄結構，這種特性使得Zookeeper不能用於存放大量的資料，每個節點的存放資料上限為1M。
4. ZAB協議？
ZAB協議是為分散式協調服務Zookeeper專門設計的一種支援崩潰恢復的原子廣播協議。
ZAB協議包括兩種基本的模式：崩潰恢復和訊息廣播。
當整個zookeeper叢集剛剛啟動或者Leader伺服器宕機、重啟或者網路故障導致不存在過半的伺服器與Leader伺服器保持正常通訊時，所有程序（伺服器）進入崩潰恢復模式，首先選舉產生新的Leader伺服器，然後叢集中Follower伺服器開始與新的Leader伺服器進行資料同步，當叢集中超過半數機器與該Leader伺服器完成資料同步之後，退出恢復模式進入訊息廣播模式，Leader伺服器開始接收客戶端的事務請求生成事物提案來進行事務請求處理。
5. 四種類型的資料節點 Znode
- PERSISTENT-持久節點
除非手動刪除，否則節點一直存在於Zookeeper上
- EPHEMERAL-臨時節點
臨時節點的生命週期與客戶端會話繫結，一旦客戶端會話失效（客戶端與zookeeper連線斷開不一定會話失效），那麼這個客戶端建立的所有臨時節點都會被移除。
- PERSISTENT_SEQUENTIAL-持久順序節點
基本特性同持久節點，只是增加了順序屬性，節點名後邊會追加一個由父節點維護的自增整型數字。
- EPHEMERAL_SEQUENTIAL-臨時順序節點
基本特性同臨時節點，增加了順序屬性，節點名後邊會追加一個由父節點維護的自增整型數字。
6. Zookeeper Watcher 機制 -- 資料變更通知
Zookeeper允許客戶端向服務端的某個Znode註冊一個Watcher監聽，當服務端的一些指定事件觸發了這個Watcher，服務端會向指定客戶端傳送一個事件通知來實現分散式的通知功能，然後客戶端根據Watcher通知狀態和事件型別做出業務上的改變。
工作機制：
- 客戶端註冊watcher
- 服務端處理watcher
- 客戶端回撥watcher
Watcher特性總結：
- 一次性
無論是服務端還是客戶端，一旦一個Watcher被觸發，Zookeeper都會將其從相應的儲存中移除。這樣的設計有效的減輕了服務端的壓力，不然對於更新非常頻繁的節點，服務端會不斷的向客戶端傳送事件通知，無論對於網路還是服務端的壓力都非常大。 - 客戶端序列執行
客戶端Watcher回撥的過程是一個串行同步的過程。 - 輕量
1）Watcher通知非常簡單，只會告訴客戶端發生了事件，而不會說明事件的具體內容。
2）客戶端向服務端註冊Watcher的時候，並不會把客戶端真實的Watcher物件實體傳遞到服務端，僅僅是在客戶端請求中使用boolean型別屬性進行了標記。
- watcher event非同步傳送watcher的通知事件從server傳送到client是非同步的，這就存在一個問題，不同的客戶端和伺服器之間通過socket進行通訊，由於網路延遲或其他因素導致客戶端在不通的時刻監聽到事件，由於Zookeeper本身提供了ordering guarantee，即客戶端監聽事件後，才會感知它所監視znode發生了變化。所以我們使用Zookeeper不能期望能夠監控到節點每次的變化。Zookeeper只能保證最終的一致性，而無法保證強一致性。
- 註冊watcher getData、exists、getChildren
- 觸發watcher create、delete、setData
- 當一個客戶端連線到一個新的伺服器上時，watch將會被以任意會話事件觸發。當與一個伺服器失去連線的時候，是無法接收到watch的。而當client重新連線時，如果需要的話，所有先前註冊過的watch，都會被重新註冊。通常這是完全透明的。只有在一個特殊情況下，watch可能會丟失：對於一個未建立的znode的exist watch，如果在客戶端斷開連線期間被建立了，並且隨後在客戶端連線上之前又刪除了，這種情況下，這個watch事件可能會被丟失。
7. 客戶端註冊Watcher實現
- 呼叫getData()/getChildren()/exist()三個API，傳入Watcher物件
- 標記請求request，封裝Watcher到WatchRegistration
- 封裝成Packet物件，發服務端傳送request
- 收到服務端響應後，將Watcher註冊到ZKWatcherManager中進行管理
- 請求返回，完成註冊。
8. 服務端處理Watcher實現
服務端接收Watcher並存儲
接收到客戶端請求，處理請求判斷是否需要註冊Watcher，需要的話將資料節點的節點路徑和ServerCnxn（ServerCnxn代表一個客戶端和服務端的連線，實現了Watcher的process介面，此時可以看成一個Watcher物件）儲存在WatcherManager的WatchTable和watch2Paths中去。
Watcher觸發
以服務端接收到 setData() 事務請求觸發NodeDataChanged事件為例：
封裝WatchedEvent
將通知狀態（SyncConnected）、事件型別（NodeDataChanged）以及節點路徑封裝成一個WatchedEvent物件
查詢Watcher
從WatchTable中根據節點路徑查詢Watcher
沒找到；說明沒有客戶端在該資料節點上註冊過Watcher
找到；提取並從WatchTable和Watch2Paths中刪除對應Watcher（從這裡可以看出Watcher在服務端是一次性的，觸發一次就失效了）
呼叫process方法來觸發Watcher
這裡process主要就是通過ServerCnxn對應的TCP連線傳送Watcher事件通知。
9. 客戶端回撥Watcher
客戶端SendThread執行緒接收事件通知，交由EventThread執行緒回撥Watcher。客戶端的Watcher機制同樣是一次性的，一旦被觸發後，該Watcher就失效了。
10. ACL許可權控制機制
UGO（User/Group/Others）
目前在Linux/Unix檔案系統中使用，也是使用最廣泛的許可權控制方式。是一種粗粒度的檔案系統許可權控制模式。
ACL（Access Control List）訪問控制列表
包括三個方面：
許可權模式（Scheme）
- IP：從IP地址粒度進行許可權控制
- Digest：最常用，用類似於 username:password 的許可權標識來進行許可權配置，便於區分不同應用來進行許可權控制
- World：最開放的許可權控制方式，是一種特殊的digest模式，只有一個許可權標識“world:anyone”
- Super：超級使用者
授權物件
- 授權物件指的是許可權賦予的使用者或一個指定實體，例如IP地址或是機器燈。
許可權 Permission
- CREATE：資料節點建立許可權，允許授權物件在該Znode下建立子節點
- DELETE：子節點刪除許可權，允許授權物件刪除該資料節點的子節點
- READ：資料節點的讀取許可權，允許授權物件訪問該資料節點並讀取其資料內容或子節點列表等
- WRITE：資料節點更新許可權，允許授權物件對該資料節點進行更新操作
- ADMIN：資料節點管理許可權，允許授權物件對該資料節點進行ACL相關設定操作
11. Chroot特性
3.2.0版本後，添加了 Chroot特性，該特性允許每個客戶端為自己設定一個名稱空間。如果一個客戶端設定了Chroot，那麼該客戶端對伺服器的任何操作，都將會被限制在其自己的名稱空間下。
通過設定Chroot，能夠將一個客戶端應用於Zookeeper服務端的一顆子樹相對應，在那些多個應用公用一個Zookeeper進群的場景下，對實現不同應用間的相互隔離非常有幫助。
12. 會話管理
分桶策略：將類似的會話放在同一區塊中進行管理，以便於Zookeeper對會話進行不同區塊的隔離處理以及同一區塊的統一處理。
分配原則：每個會話的“下次超時時間點”（ExpirationTime）
計算公式：
ExpirationTime_ = currentTime + sessionTimeout
ExpirationTime = (ExpirationTime_ / ExpirationInrerval + 1) * ExpirationInterval , ExpirationInterval 是指 Zookeeper 會話超時檢查時間間隔，預設 tickTime
13. 伺服器角色
Leader
- 事務請求的唯一排程和處理者，保證叢集事務處理的順序性
- 叢集內部各服務的排程者
Follower
- 處理客戶端的非事務請求，轉發事務請求給Leader伺服器
- 參與事務請求Proposal的投票
- 參與Leader選舉投票
Observer
- 3.3.0版本以後引入的一個伺服器角色，在不影響叢集事務處理能力的基礎上提升叢集的非事務處理能力
- 處理客戶端的非事務請求，轉發事務請求給Leader伺服器
- 不參與任何形式的投票
14. Zookeeper 下 Server工作狀態
伺服器具有四種狀態，分別是LOOKING、FOLLOWING、LEADING、OBSERVING。
- LOOKING：尋找Leader狀態。當伺服器處於該狀態時，它會認為當前叢集中沒有Leader，因此需要進入Leader選舉狀態。
- FOLLOWING：跟隨者狀態。表明當前伺服器角色是Follower。
- LEADING：領導者狀態。表明當前伺服器角色是Leader。
- OBSERVING：觀察者狀態。表明當前伺服器角色是Observer。
15. Leader 選舉
Leader選舉是保證分散式資料一致性的關鍵所在。當Zookeeper叢集中的一臺伺服器出現以下兩種情況之一時，需要進入Leader選舉。
(1) 伺服器初始化啟動。
(2) 伺服器執行期間無法和Leader保持連線。
下面就兩種情況進行分析講解。
1. 伺服器啟動時期的Leader選舉
若進行Leader選舉，則至少需要兩臺機器，這裡選取3臺機器組成的伺服器叢集為例。在叢集初始化階段，當有一臺伺服器Server1啟動時，其單獨無法進行和完成Leader選舉，當第二臺伺服器Server2啟動時，此時兩臺機器可以相互通訊，每臺機器都試圖找到Leader，於是進入Leader選舉過程。選舉過程如下
(1) 每個Server發出一個投票。由於是初始情況，Server1和Server2都會將自己作為Leader伺服器來進行投票，每次投票會包含所推舉的伺服器的myid和ZXID，使用(myid, ZXID)來表示，此時Server1的投票為(1, 0)，Server2的投票為(2, 0)，然後各自將這個投票發給叢集中其他機器。
(2) 接受來自各個伺服器的投票。叢集的每個伺服器收到投票後，首先判斷該投票的有效性，如檢查是否是本輪投票、是否來自LOOKING狀態的伺服器。
(3) 處理投票。針對每一個投票，伺服器都需要將別人的投票和自己的投票進行PK，PK規則如下
· 優先檢查ZXID。ZXID比較大的伺服器優先作為Leader。
· 如果ZXID相同，那麼就比較myid。myid較大的伺服器作為Leader伺服器。
對於Server1而言，它的投票是(1, 0)，接收Server2的投票為(2, 0)，首先會比較兩者的ZXID，均為0，再比較myid，此時Server2的myid最大，於是更新自己的投票為(2, 0)，然後重新投票，對於Server2而言，其無須更新自己的投票，只是再次向叢集中所有機器發出上一次投票資訊即可。
(4) 統計投票。每次投票後，伺服器都會統計投票資訊，判斷是否已經有過半機器接受到相同的投票資訊，對於Server1、Server2而言，都統計出叢集中已經有兩臺機器接受了(2, 0)的投票資訊，此時便認為已經選出了Leader。
(5) 改變伺服器狀態。一旦確定了Leader，每個伺服器就會更新自己的狀態，如果是Follower，那麼就變更為FOLLOWING，如果是Leader，就變更為LEADING。
2. 伺服器執行時期的Leader選舉
在Zookeeper執行期間，Leader與非Leader伺服器各司其職，即便當有非Leader伺服器宕機或新加入，此時也不會影響Leader，但是一旦Leader伺服器掛了，那麼整個叢集將暫停對外服務，進入新一輪Leader選舉，其過程和啟動時期的Leader選舉過程基本一致。假設正在執行的有Server1、Server2、Server3三臺伺服器，當前Leader是Server2，若某一時刻Leader掛了，此時便開始Leader選舉。選舉過程如下
(1) 變更狀態。Leader掛後，餘下的非Observer伺服器都會講自己的伺服器狀態變更為LOOKING，然後開始進入Leader選舉過程。
(2) 每個Server會發出一個投票。在執行期間，每個伺服器上的ZXID可能不同，此時假定Server1的ZXID為123，Server3的ZXID為122；在第一輪投票中，Server1和Server3都會投自己，產生投票(1, 123)，(3, 122)，然後各自將投票傳送給叢集中所有機器。
(3) 接收來自各個伺服器的投票。與啟動時過程相同。
(4) 處理投票。與啟動時過程相同，此時，Server1將會成為Leader。
(5) 統計投票。與啟動時過程相同。
(6) 改變伺服器的狀態。與啟動時過程相同。
2.2 Leader選舉演算法分析
在3.4.0後的Zookeeper的版本只保留了TCP版本的FastLeaderElection選舉演算法。當一臺機器進入Leader選舉時，當前叢集可能會處於以下兩種狀態
· 叢集中已經存在Leader。
· 叢集中不存在Leader。
對於叢集中已經存在Leader而言，此種情況一般都是某臺機器啟動得較晚，在其啟動之前，叢集已經在正常工作，對這種情況，該機器試圖去選舉Leader時，會被告知當前伺服器的Leader資訊，對於該機器而言，僅僅需要和Leader機器建立起連線，並進行狀態同步即可。而在叢集中不存在Leader情況下則會相對複雜，其步驟如下
(1) 第一次投票。無論哪種導致進行Leader選舉，叢集的所有機器都處於試圖選舉出一個Leader的狀態，即LOOKING狀態，LOOKING機器會向所有其他機器傳送訊息，該訊息稱為投票。投票中包含了SID（伺服器的唯一標識）和ZXID（事務ID），(SID, ZXID)形式來標識一次投票資訊。假定Zookeeper由5臺機器組成，SID分別為1、2、3、4、5，ZXID分別為9、9、9、8、8，並且此時SID為2的機器是Leader機器，某一時刻，1、2所在機器出現故障，因此叢集開始進行Leader選舉。在第一次投票時，每臺機器都會將自己作為投票物件，於是SID為3、4、5的機器投票情況分別為(3, 9)，(4, 8)， (5, 8)。
(2) 變更投票。每臺機器發出投票後，也會收到其他機器的投票，每臺機器會根據一定規則來處理收到的其他機器的投票，並以此來決定是否需要變更自己的投票，這個規則也是整個Leader選舉演算法的核心所在，其中術語描述如下
· vote_sid：接收到的投票中所推舉Leader伺服器的SID。
· vote_zxid：接收到的投票中所推舉Leader伺服器的ZXID。
· self_sid：當前伺服器自己的SID。
· self_zxid：當前伺服器自己的ZXID。
每次對收到的投票的處理，都是對(vote_sid, vote_zxid)和(self_sid, self_zxid)對比的過程。
規則一：如果vote_zxid大於self_zxid，就認可當前收到的投票，並再次將該投票傳送出去。
規則二：如果vote_zxid小於self_zxid，那麼堅持自己的投票，不做任何變更。
規則三：如果vote_zxid等於self_zxid，那麼就對比兩者的SID，如果vote_sid大於self_sid，那麼就認可當前收到的投票，並再次將該投票傳送出去。
規則四：如果vote_zxid等於self_zxid，並且vote_sid小於self_sid，那麼堅持自己的投票，不做任何變更。
結合上面規則，給出下面的叢集變更過程。
(3) 確定Leader。經過第二輪投票後，叢集中的每臺機器都會再次接收到其他機器的投票，然後開始統計投票，如果一臺機器收到了超過半數的相同投票，那麼這個投票對應的SID機器即為Leader。此時Server3將成為Leader。
由上面規則可知，通常那臺伺服器上的資料越新（ZXID會越大），其成為Leader的可能性越大，也就越能夠保證資料的恢復。如果ZXID相同，則SID越大機會越大。
2.3 Leader選舉實現細節
1. 伺服器狀態
伺服器具有四種狀態，分別是LOOKING、FOLLOWING、LEADING、OBSERVING。
LOOKING：尋找Leader狀態。當伺服器處於該狀態時，它會認為當前叢集中沒有Leader，因此需要進入Leader選舉狀態。
FOLLOWING：跟隨者狀態。表明當前伺服器角色是Follower。
LEADING：領導者狀態。表明當前伺服器角色是Leader。
OBSERVING：觀察者狀態。表明當前伺服器角色是Observer。
2. 投票資料結構
每個投票中包含了兩個最基本的資訊，所推舉伺服器的SID和ZXID，投票（Vote）在Zookeeper中包含欄位如下
id：被推舉的Leader的SID。
zxid：被推舉的Leader事務ID。
electionEpoch：邏輯時鐘，用來判斷多個投票是否在同一輪選舉週期中，該值在服務端是一個自增序列，每次進入新一輪的投票後，都會對該值進行加1操作。
peerEpoch：被推舉的Leader的epoch。
state：當前伺服器的狀態。
3. QuorumCnxManager：網路I/O
每臺伺服器在啟動的過程中，會啟動一個QuorumPeerManager，負責各臺伺服器之間的底層Leader選舉過程中的網路通訊。
(1) 訊息佇列。QuorumCnxManager內部維護了一系列的佇列，用來儲存接收到的、待發送的訊息以及訊息的傳送器，除接收佇列以外，其他佇列都按照SID分組形成佇列集合，如一個叢集中除了自身還有3臺機器，那麼就會為這3臺機器分別建立一個傳送佇列，互不干擾。
· recvQueue：訊息接收佇列，用於存放那些從其他伺服器接收到的訊息。
· queueSendMap：訊息傳送佇列，用於儲存那些待發送的訊息，按照SID進行分組。
· senderWorkerMap：傳送器集合，每個SenderWorker訊息傳送器，都對應一臺遠端Zookeeper伺服器，負責訊息的傳送，也按照SID進行分組。
· lastMessageSent：最近傳送過的訊息，為每個SID保留最近傳送過的一個訊息。
(2) 建立連線。為了能夠相互投票，Zookeeper叢集中的所有機器都需要兩兩建立起網路連線。QuorumCnxManager在啟動時會建立一個ServerSocket來監聽Leader選舉的通訊埠(預設為3888)。開啟監聽後，Zookeeper能夠不斷地接收到來自其他伺服器的建立連線請求，在接收到其他伺服器的TCP連線請求時，會進行處理。為了避免兩臺機器之間重複地建立TCP連線，Zookeeper只允許SID大的伺服器主動和其他機器建立連線，否則斷開連線。在接收到建立連線請求後，伺服器通過對比自己和遠端伺服器的SID值來判斷是否接收連線請求，如果當前伺服器發現自己的SID更大，那麼會斷開當前連線，然後自己主動和遠端伺服器建立連線。一旦連線建立，就會根據遠端伺服器的SID來建立相應的訊息傳送器SendWorker和訊息接收器RecvWorker，並啟動。
(3) 訊息接收與傳送。訊息接收：由訊息接收器RecvWorker負責，由於Zookeeper為每個遠端伺服器都分配一個單獨的RecvWorker，因此，每個RecvWorker只需要不斷地從這個TCP連線中讀取訊息，並將其儲存到recvQueue佇列中。訊息傳送：由於Zookeeper為每個遠端伺服器都分配一個單獨的SendWorker，因此，每個SendWorker只需要不斷地從對應的訊息傳送佇列中獲取出一個訊息傳送即可，同時將這個訊息放入lastMessageSent中。在SendWorker中，一旦Zookeeper發現針對當前伺服器的訊息傳送佇列為空，那麼此時需要從lastMessageSent中取出一個最近傳送過的訊息來進行再次傳送，這是為了解決接收方在訊息接收前或者接收到訊息後伺服器掛了，導致訊息尚未被正確處理。同時，Zookeeper能夠保證接收方在處理訊息時，會對重複訊息進行正確的處理。
4. FastLeaderElection：選舉演算法核心
· 外部投票：特指其他伺服器發來的投票。
· 內部投票：伺服器自身當前的投票。
· 選舉輪次：Zookeeper伺服器Leader選舉的輪次，即logicalclock。
· PK：對內部投票和外部投票進行對比來確定是否需要變更內部投票。
(1) 選票管理
· sendqueue：選票傳送佇列，用於儲存待發送的選票。
· recvqueue：選票接收佇列，用於儲存接收到的外部投票。
· WorkerReceiver：選票接收器。其會不斷地從QuorumCnxManager中獲取其他伺服器發來的選舉訊息，並將其轉換成一個選票，然後儲存到recvqueue中，在選票接收過程中，如果發現該外部選票的選舉輪次小於當前伺服器的，那麼忽略該外部投票，同時立即傳送自己的內部投票。
· WorkerSender：選票傳送器，不斷地從sendqueue中獲取待發送的選票，並將其傳遞到底層QuorumCnxManager中。
(2) 演算法核心
上圖展示了FastLeaderElection模組是如何與底層網路I/O進行互動的。Leader選舉的基本流程如下
1. 自增選舉輪次。Zookeeper規定所有有效的投票都必須在同一輪次中，在開始新一輪投票時，會首先對logicalclock進行自增操作。
2. 初始化選票。在開始進行新一輪投票之前，每個伺服器都會初始化自身的選票，並且在初始化階段，每臺伺服器都會將自己推舉為Leader。
3. 傳送初始化選票。完成選票的初始化後，伺服器就會發起第一次投票。Zookeeper會將剛剛初始化好的選票放入sendqueue中，由傳送器WorkerSender負責傳送出去。
4. 接收外部投票。每臺伺服器會不斷地從recvqueue佇列中獲取外部選票。如果伺服器發現無法獲取到任何外部投票，那麼就會立即確認自己是否和叢集中其他伺服器保持著有效的連線，如果沒有連線，則馬上建立連線，如果已經建立了連線，則再次傳送自己當前的內部投票。
5. 判斷選舉輪次。在傳送完初始化選票之後，接著開始處理外部投票。在處理外部投票時，會根據選舉輪次來進行不同的處理。
· 外部投票的選舉輪次大於內部投票。若伺服器自身的選舉輪次落後於該外部投票對應伺服器的選舉輪次，那麼就會立即更新自己的選舉輪次(logicalclock)，並且清空所有已經收到的投票，然後使用初始化的投票來進行PK以確定是否變更內部投票。最終再將內部投票傳送出去。
· 外部投票的選舉輪次小於內部投票。若伺服器接收的外選票的選舉輪次落後於自身的選舉輪次，那麼Zookeeper就會直接忽略該外部投票，不做任何處理，並返回步驟4。
· 外部投票的選舉輪次等於內部投票。此時可以開始進行選票PK。
6. 選票PK。在進行選票PK時，符合任意一個條件就需要變更投票。
· 若外部投票中推舉的Leader伺服器的選舉輪次大於內部投票，那麼需要變更投票。
· 若選舉輪次一致，那麼就對比兩者的ZXID，若外部投票的ZXID大，那麼需要變更投票。
· 若兩者的ZXID一致，那麼就對比兩者的SID，若外部投票的SID大，那麼就需要變更投票。
7. 變更投票。經過PK後，若確定了外部投票優於內部投票，那麼就變更投票，即使用外部投票的選票資訊來覆蓋內部投票，變更完成後，再次將這個變更後的內部投票傳送出去。
8. 選票歸檔。無論是否變更了投票，都會將剛剛收到的那份外部投票放入選票集合recvset中進行歸檔。recvset用於記錄當前伺服器在本輪次的Leader選舉中收到的所有外部投票（按照服務隊的SID區別，如{(1, vote1), (2, vote2)...}）。
9. 統計投票。完成選票歸檔後，就可以開始統計投票，統計投票是為了統計叢集中是否已經有過半的伺服器認可了當前的內部投票，如果確定已經有過半伺服器認可了該投票，則終止投票。否則返回步驟4。
10. 更新伺服器狀態。若已經確定可以終止投票，那麼就開始更新伺服器狀態，伺服器首選判斷當前被過半伺服器認可的投票所對應的Leader伺服器是否是自己，若是自己，則將自己的伺服器狀態更新為LEADING，若不是，則根據具體情況來確定自己是FOLLOWING或是OBSERVING。
以上10個步驟就是FastLeaderElection的核心，其中步驟4-9會經過幾輪迴圈，直到有Leader選舉產生。
16. 資料同步
整個叢集完成Leader選舉之後，Learner（Follower和Observer的統稱）迴向Leader伺服器進行註冊。當Learner伺服器想Leader伺服器完成註冊後，進入資料同步環節。
資料同步流程：（均以訊息傳遞的方式進行）
- i. Learner向Learder註冊
- ii. 資料同步
- iii. 同步確認
Zookeeper的資料同步通常分為四類：
- 直接差異化同步（DIFF同步）
- 先回滾再差異化同步（TRUNC+DIFF同步）
- 僅回滾同步（TRUNC同步）
- 全量同步（SNAP同步）
在進行資料同步前，Leader伺服器會完成資料同步初始化：
- peerLastZxid：從learner伺服器註冊時傳送的ACKEPOCH訊息中提取lastZxid（該Learner伺服器最後處理的ZXID）
- minCommittedLog：Leader伺服器Proposal快取佇列committedLog中最小ZXID
- maxCommittedLog：Leader伺服器Proposal快取佇列committedLog中最大ZXID
直接差異化同步（DIFF同步）
- 場景：peerLastZxid介於minCommittedLog和maxCommittedLog之間
先回滾再差異化同步（TRUNC+DIFF同步）
- 場景：當新的Leader伺服器發現某個Learner伺服器包含了一條自己沒有的事務記錄，那麼就需要讓該Learner伺服器進行事務回滾--回滾到Leader伺服器上存在的，同時也是最接近於peerLastZxid的ZXID
僅回滾同步（TRUNC同步）
- 場景：peerLastZxid 大於 maxCommittedLog
全量同步（SNAP同步）
- 場景一：peerLastZxid 小於 minCommittedLog
- 場景二：Leader伺服器上沒有Proposal快取佇列且peerLastZxid不等於lastProcessZxid
17. zookeeper是如何保證事務的順序一致性的？
zookeeper採用了全域性遞增的事務Id來標識，所有的proposal（提議）都在被提出的時候加上了zxid，zxid實際上是一個64位的數字，高32位是epoch（時期; 紀元; 世; 新時代）用來標識leader週期，如果有新的leader產生出來，epoch會自增，低32位用來遞增計數。當新產生proposal的時候，會依據資料庫的兩階段過程，首先會向其他的server發出事務執行請求，如果超過半數的機器都能執行並且能夠成功，那麼就會開始執行。
18. 分散式叢集中為什麼會有Master？
在分散式環境中，有些業務邏輯只需要叢集中的某一臺機器進行執行，其他的機器可以共享這個結果，這樣可以大大減少重複計算，提高效能，於是就需要進行leader選舉。
19. zk節點宕機如何處理？
Zookeeper本身也是叢集，推薦配置不少於3個伺服器。Zookeeper自身也要保證當一個節點宕機時，其他節點會繼續提供服務。
如果是一個Follower宕機，還有2臺伺服器提供訪問，因為Zookeeper上的資料是有多個副本的，資料並不會丟失；
如果是一個Leader宕機，Zookeeper會選舉出新的Leader。
ZK叢集的機制是隻要超過半數的節點正常，叢集就能正常提供服務。只有在ZK節點掛得太多，只剩一半或不到一半節點能工作，叢集才失效。
所以
3個節點的cluster可以掛掉1個節點(leader可以得到2票>1.5)
2個節點的cluster就不能掛掉任何1個節點了(leader可以得到1票<=1)
20. zookeeper負載均衡和nginx負載均衡區別
zk的負載均衡是可以調控，nginx只是能調權重，其他需要可控的都需要自己寫外掛；但是nginx的吞吐量比zk大很多，應該說按業務選擇用哪種方式。
21. Zookeeper有哪幾種幾種部署模式？
部署模式：單機模式、偽叢集模式、叢集模式。
22. 叢集最少要幾臺機器，叢集規則是怎樣的?
叢集規則為2N+1臺，N>0，即3臺。
23. 叢集支援動態新增機器嗎？
其實就是水平擴容了，Zookeeper在這方面不太好。兩種方式：
全部重啟：關閉所有Zookeeper服務，修改配置之後啟動。不影響之前客戶端的會話。
逐個重啟：在過半存活即可用的原則下，一臺機器重啟不影響整個叢集對外提供服務。這是比較常用的方式。
3.5版本開始支援動態擴容。
24. Zookeeper對節點的watch監聽通知是永久的嗎？為什麼不是永久的?
不是。官方宣告：一個Watch事件是一個一次性的觸發器，當被設定了Watch的資料發生了改變的時候，則伺服器將這個改變傳送給設定了Watch的客戶端，以便通知它們。
為什麼不是永久的，舉個例子，如果服務端變動頻繁，而監聽的客戶端很多情況下，每次變動都要通知到所有的客戶端，給網路和伺服器造成很大壓力。
一般是客戶端執行getData(“/節點A”,true)，如果節點A發生了變更或刪除，客戶端會得到它的watch事件，但是在之後節點A又發生了變更，而客戶端又沒有設定watch事件，就不再給客戶端傳送。
在實際應用中，很多情況下，我們的客戶端不需要知道服務端的每一次變動，我只要最新的資料即可。
25. Zookeeper的java客戶端都有哪些？
java客戶端：zk自帶的zkclient及Apache開源的Curator。
26. chubby是什麼，和zookeeper比你怎麼看？
chubby是google的，完全實現paxos演算法，不開源。zookeeper是chubby的開源實現，使用zab協議，paxos演算法的變種。
27. 說幾個zookeeper常用的命令。
常用命令：ls get set create delete等。
28. ZAB和Paxos演算法的聯絡與區別？
相同點：
兩者都存在一個類似於Leader程序的角色，由其負責協調多個Follower程序的執行
Leader程序都會等待超過半數的Follower做出正確的反饋後，才會將一個提案進行提交
ZAB協議中，每個Proposal中都包含一個 epoch 值來代表當前的Leader週期，Paxos中名字為Ballot
不同點：
ZAB用來構建高可用的分散式資料主備系統（Zookeeper），Paxos是用來構建分散式一致性狀態機系統。
29. Zookeeper的典型應用場景
Zookeeper是一個典型的釋出/訂閱模式的分散式資料管理與協調框架，開發人員可以使用它來進行分散式資料的釋出和訂閱。
通過對Zookeeper中豐富的資料節點進行交叉使用，配合Watcher事件通知機制，可以非常方便的構建一系列分散式應用中年都會涉及的核心功能，如：
- 資料釋出/訂閱
- 負載均衡
- 命名服務
- 分散式協調/通知
- 叢集管理
- Master選舉
- 分散式鎖
- 分散式佇列
1. 資料釋出/訂閱
介紹
資料釋出/訂閱系統，即所謂的配置中心，顧名思義就是釋出者釋出資料供訂閱者進行資料訂閱。
目的
- 動態獲取資料（配置資訊）
- 實現資料（配置資訊）的集中式管理和資料的動態更新
設計模式
- Push 模式
- Pull 模式
資料（配置資訊）特性
- 資料量通常比較小
- 資料內容在執行時會發生動態更新
- 叢集中各機器共享，配置一致
如：機器列表資訊、執行時開關配置、資料庫配置資訊等
基於Zookeeper的實現方式
- 資料儲存：將資料（配置資訊）儲存到Zookeeper上的一個數據節點
- 資料獲取：應用在啟動初始化節點從Zookeeper資料節點讀取資料，並在該節點上註冊一個數據變更Watcher
- 資料變更：當變更資料時，更新Zookeeper對應節點資料，Zookeeper會將資料變更通知發到各客戶端，客戶端接到通知後重新讀取變更後的資料即可。
2. 負載均衡
zk的命名服務
命名服務是指通過指定的名字來獲取資源或者服務的地址，利用zk建立一個全域性的路徑，這個路徑就可以作為一個名字，指向叢集中的叢集，提供的服務的地址，或者一個遠端的物件等等。
分散式通知和協調
對於系統排程來說：操作人員傳送通知實際是通過控制檯改變某個節點的狀態，然後zk將這些變化傳送給註冊了這個節點的watcher的所有客戶端。
對於執行情況彙報：每個工作程序都在某個目錄下建立一個臨時節點。並攜帶工作的進度資料，這樣彙總的程序可以監控目錄子節點的變化獲得工作進度的實時的全域性情況。
3.zk的命名服務（檔案系統）
命名服務是指通過指定的名字來獲取資源或者服務的地址，利用zk建立一個全域性的路徑，即是唯一的路徑，這個路徑就可以作為一個名字，指向叢集中的叢集，提供的服務的地址，或者一個遠端的物件等等。
4.zk的配置管理（檔案系統、通知機制）
程式分散式的部署在不同的機器上，將程式的配置資訊放在zk的znode下，當有配置發生改變時，也就是znode發生變化時，可以通過改變zk中某個目錄節點的內容，利用watcher通知給各個客戶端，從而更改配置。
5.Zookeeper叢集管理（檔案系統、通知機制）
所謂叢集管理無在乎兩點：是否有機器退出和加入、選舉master。
對於第一點，所有機器約定在父目錄下建立臨時目錄節點，然後監聽父目錄節點的子節點變化訊息。一旦有機器掛掉，該機器與 zookeeper的連線斷開，其所建立的臨時目錄節點被刪除，所有其他機器都收到通知：某個兄弟目錄被刪除，於是，所有人都知道：它上船了。
新機器加入也是類似，所有機器收到通知：新兄弟目錄加入，highcount又有了，對於第二點，我們稍微改變一下，所有機器建立臨時順序編號目錄節點，每次選取編號最小的機器作為master就好。
6.Zookeeper分散式鎖（檔案系統、通知機制）
有了zookeeper的一致性檔案系統，鎖的問題變得容易。鎖服務可以分為兩類，一個是保持獨佔，另一個是控制時序。
對於第一類，我們將zookeeper上的一個znode看作是一把鎖，通過createznode的方式來實現。所有客戶端都去建立 /distribute_lock 節點，最終成功建立的那個客戶端也即擁有了這把鎖。用完刪除掉自己建立的distribute_lock 節點就釋放出鎖。
對於第二類， /distribute_lock 已經預先存在，所有客戶端在它下面建立臨時順序編號目錄節點，和選master一樣，編號最小的獲得鎖，用完刪除，依次方便。
7.獲取分散式鎖的流程
clipboard.png
在獲取分散式鎖的時候在locker節點下建立臨時順序節點，釋放鎖的時候刪除該臨時節點。客戶端呼叫createNode方法在locker下建立臨時順序節點，
然後呼叫getChildren(“locker”)來獲取locker下面的所有子節點，注意此時不用設定任何Watcher。客戶端獲取到所有的子節點path之後，如果發現自己建立的節點在所有建立的子節點序號最小，那麼就認為該客戶端獲取到了鎖。如果發現自己建立的節點並非locker所有子節點中最小的，說明自己還沒有獲取到鎖，此時客戶端需要找到比自己小的那個節點，然後對其呼叫exist()方法，同時對其註冊事件監聽器。之後，讓這個被關注的節點刪除，則客戶端的Watcher會收到相應通知，此時再次判斷自己建立的節點是否是locker子節點中序號最小的，如果是則獲取到了鎖，如果不是則重複以上步驟繼續獲取到比自己小的一個節點並註冊監聽。當前這個過程中還需要許多的邏輯判斷。
clipboard.png
程式碼的實現主要是基於互斥鎖，獲取分散式鎖的重點邏輯在於BaseDistributedLock，實現了基於Zookeeper實現分散式鎖的細節。
8.Zookeeper佇列管理（檔案系統、通知機制）
兩種型別的佇列：
1、同步佇列，當一個佇列的成員都聚齊時，這個佇列才可用，否則一直等待所有成員到達。
2、佇列按照 FIFO 方式進行入隊和出隊操作。
第一類，在約定目錄下建立臨時目錄節點，監聽節點數目是否是我們要求的數目。
第二類，和分散式鎖服務中的控制時序場景基本原理一致，入列有編號，出列按編號。在特定的目錄下建立PERSISTENT_SEQUENTIAL節點，建立成功時Watcher通知等待的佇列，佇列刪除序列號最小的節點用以消費。此場景下Zookeeper的znode用於訊息儲存，znode儲存的資料就是訊息佇列中的訊息內容，SEQUENTIAL序列號就是訊息的編號，按序取出即可。由於建立的節點是持久化的，所以不必擔心佇列訊息的丟失問