Zookeeper面試題

1. ZooKeeper是什麼？

ZooKeeper是一個開放源碼的分佈式協調服務，它是集羣的管理者，監視着集羣中各個節點的狀態根據節點提交的反饋進行下一步合理操做。最終，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶。

分佈式應用程序能夠基於Zookeeper實現諸如數據發佈/訂閱、負載均衡、命名服務、分佈式協調/通知、集羣管理、Master選舉、分佈式鎖和分佈式隊列等功能。

Zookeeper保證了以下分佈式一致性特性：

• 順序一致性
• 原子性
• 單一視圖
• 可靠性
• 實時性（最終一致性）

客戶端的讀請求能夠被集羣中的任意一臺機器處理，若是讀請求在節點上註冊了監聽器，這個監聽器也是由所鏈接的zookeeper機器來處理。對於寫請求，這些請求會同時發給其餘zookeeper機器而且達成一致後，請求才會返回成功。所以，隨着zookeeper的集羣機器增多，讀請求的吞吐會提升可是寫請求的吞吐會降低。

有序性是zookeeper中很是重要的一個特性，全部的更新都是全局有序的，每一個更新都有一個惟一的時間戳，這個時間戳稱爲zxid（Zookeeper Transaction Id）。而讀請求只會相對於更新有序，也就是讀請求的返回結果中會帶有這個zookeeper最新的zxid。

2. ZooKeeper提供了什麼？

一、文件系統
二、通知機制

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特性總結：

1. 一次性
   不管是服務端仍是客戶端，一旦一個Watcher被觸發，Zookeeper都會將其從相應的存儲中移除。這樣的設計有效的減輕了服務端的壓力，否則對於更新很是頻繁的節點，服務端會不斷的向客戶端發送事件通知，不管對於網絡仍是服務端的壓力都很是大。
2. 客戶端串行執行
   客戶端Watcher回調的過程是一個串行同步的過程。
3. 輕量
   • Watcher通知很是簡單，只會告訴客戶端發生了事件，而不會說明事件的具體內容。
   • 客戶端向服務端註冊Watcher的時候，並不會把客戶端真實的Watcher對象實體傳遞到服務端，僅僅是在客戶端請求中使用boolean類型屬性進行了標記。
4. watcher event異步發送watcher的通知事件從server發送到client是異步的，這就存在一個問題，不一樣的客戶端和服務器之間經過socket進行通訊，因爲網絡延遲或其餘因素致使客戶端在不通的時刻監聽到事件，因爲Zookeeper自己提供了ordering guarantee，即客戶端監聽事件後，纔會感知它所監視znode發生了變化。因此咱們使用Zookeeper不能指望可以監控到節點每次的變化。Zookeeper只能保證最終的一致性，而沒法保證強一致性。
5. 註冊watcher getData、exists、getChildren
6. 觸發watcher create、delete、setData
7. 當一個客戶端鏈接到一個新的服務器上時，watch將會被以任意會話事件觸發。當與一個服務器失去鏈接的時候，是沒法接收到watch的。而當client從新鏈接時，若是須要的話，全部先前註冊過的watch，都會被從新註冊。一般這是徹底透明的。只有在一個特殊狀況下，watch可能會丟失：對於一個未建立的znode的exist watch，若是在客戶端斷開鏈接期間被建立了，而且隨後在客戶端鏈接上以前又刪除了，這種狀況下，這個watch事件可能會被丟失。

7. 客戶端註冊Watcher實現

1. 調用getData()/getChildren()/exist()三個API，傳入Watcher對象
2. 標記請求request，封裝Watcher到WatchRegistration
3. 封裝成Packet對象，發服務端發送request
4. 收到服務端響應後，將Watcher註冊到ZKWatcherManager中進行管理
5. 請求返回，完成註冊。

8. 服務端處理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事件通知。

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) 統計投票。每次投票後，服務器都會統計投票信息，判斷是否已經有過半機器接受到相同的投票信息，對於Server一、Server2而言，都統計出集羣中已經有兩臺機器接受了(2, 0)的投票信息，此時便認爲已經選出了Leader。

　　(5) 改變服務器狀態。一旦肯定了Leader，每一個服務器就會更新本身的狀態，若是是Follower，那麼就變動爲FOLLOWING，若是是Leader，就變動爲LEADING。

　　2. 服務器運行時期的Leader選舉

　　在Zookeeper運行期間，Leader與非Leader服務器各司其職，即使當有非Leader服務器宕機或新加入，此時也不會影響Leader，可是一旦Leader服務器掛了，那麼整個集羣將暫停對外服務，進入新一輪Leader選舉，其過程和啓動時期的Leader選舉過程基本一致。假設正在運行的有Server一、Server二、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分別爲一、二、三、四、5，ZXID分別爲九、九、九、八、8，而且此時SID爲2的機器是Leader機器，某一時刻，一、2所在機器出現故障，所以集羣開始進行Leader選舉。在第一次投票時，每臺機器都會將本身做爲投票對象，因而SID爲三、四、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的實現方式

1. 數據存儲：將數據（配置信息）存儲到Zookeeper上的一個數據節點
2. 數據獲取：應用在啓動初始化節點從Zookeeper數據節點讀取數據，並在該節點上註冊一個數據變動Watcher
3. 數據變動：當變動數據時，更新Zookeeper對應節點數據，Zookeeper會將數據變動通知發到各客戶端，客戶端接到通知後從新讀取變動後的數據便可。

2. 負載均衡

zk的命名服務
命名服務是指經過指定的名字來獲取資源或者服務的地址，利用zk建立一個全局的路徑，這個路徑就能夠做爲一個名字，指向集羣中的集羣，提供的服務的地址，或者一個遠程的對象等等。

分佈式通知和協調
對於系統調度來講：操做人員發送通知實際是經過控制檯改變某個節點的狀態，而後zk將這些變化發送給註冊了這個節點的watcher的全部客戶端。
對於執行狀況彙報：每一個工做進程都在某個目錄下建立一個臨時節點。並攜帶工做的進度數據，這樣彙總的進程能夠監控目錄子節點的變化得到工做進度的實時的全局狀況。

7.zk的命名服務（文件系統）
命名服務是指經過指定的名字來獲取資源或者服務的地址，利用zk建立一個全局的路徑，便是惟一的路徑，這個路徑就能夠做爲一個名字，指向集羣中的集羣，提供的服務的地址，或者一個遠程的對象等等。

8.zk的配置管理（文件系統、通知機制）
程序分佈式的部署在不一樣的機器上，將程序的配置信息放在zk的znode下，當有配置發生改變時，也就是znode發生變化時，能夠經過改變zk中某個目錄節點的內容，利用watcher通知給各個客戶端，從而更改配置。

9.Zookeeper集羣管理（文件系統、通知機制）
所謂集羣管理無在意兩點：是否有機器退出和加入、選舉master。
對於第一點，全部機器約定在父目錄下建立臨時目錄節點，而後監聽父目錄節點的子節點變化消息。一旦有機器掛掉，該機器與 zookeeper的鏈接斷開，其所建立的臨時目錄節點被刪除，全部其餘機器都收到通知：某個兄弟目錄被刪除，因而，全部人都知道：它上船了。
新機器加入也是相似，全部機器收到通知：新兄弟目錄加入，highcount又有了，對於第二點，咱們稍微改變一下，全部機器建立臨時順序編號目錄節點，每次選取編號最小的機器做爲master就好。

10.Zookeeper分佈式鎖（文件系統、通知機制）
有了zookeeper的一致性文件系統，鎖的問題變得容易。鎖服務能夠分爲兩類，一個是保持獨佔，另外一個是控制時序。
對於第一類，咱們將zookeeper上的一個znode看做是一把鎖，經過createznode的方式來實現。全部客戶端都去建立 /distribute_lock 節點，最終成功建立的那個客戶端也即擁有了這把鎖。用完刪除掉本身建立的distribute_lock 節點就釋放出鎖。
對於第二類， /distribute_lock 已經預先存在，全部客戶端在它下面建立臨時順序編號目錄節點，和選master同樣，編號最小的得到鎖，用完刪除，依次方便。

11.獲取分佈式鎖的流程
clipboard.png

在獲取分佈式鎖的時候在locker節點下建立臨時順序節點，釋放鎖的時候刪除該臨時節點。客戶端調用createNode方法在locker下建立臨時順序節點，
而後調用getChildren(「locker」)來獲取locker下面的全部子節點，注意此時不用設置任何Watcher。客戶端獲取到全部的子節點path以後，若是發現本身建立的節點在全部建立的子節點序號最小，那麼就認爲該客戶端獲取到了鎖。若是發現本身建立的節點並不是locker全部子節點中最小的，說明本身尚未獲取到鎖，此時客戶端須要找到比本身小的那個節點，而後對其調用exist()方法，同時對其註冊事件監聽器。以後，讓這個被關注的節點刪除，則客戶端的Watcher會收到相應通知，此時再次判斷本身建立的節點是不是locker子節點中序號最小的，若是是則獲取到了鎖，若是不是則重複以上步驟繼續獲取到比本身小的一個節點並註冊監聽。當前這個過程當中還須要許多的邏輯判斷。
clipboard.png

代碼的實現主要是基於互斥鎖，獲取分佈式鎖的重點邏輯在於BaseDistributedLock，實現了基於Zookeeper實現分佈式鎖的細節。

12.Zookeeper隊列管理（文件系統、通知機制） 兩種類型的隊列： 一、同步隊列，當一個隊列的成員都聚齊時，這個隊列纔可用，不然一直等待全部成員到達。 二、隊列按照 FIFO 方式進行入隊和出隊操做。 第一類，在約定目錄下建立臨時目錄節點，監聽節點數目是不是咱們要求的數目。 第二類，和分佈式鎖服務中的控制時序場景基本原理一致，入列有編號，出列按編號。在特定的目錄下建立PERSISTENT_SEQUENTIAL節點，建立成功時Watcher通知等待的隊列，隊列刪除序列號最小的節點用以消費。此場景下Zookeeper的znode用於消息存儲，znode存儲的數據就是消息隊列中的消息內容，SEQUENTIAL序列號就是消息的編號，按序取出便可。因爲建立的節點是持久化的，因此沒必要擔憂隊列消息的丟失問題。