深刻分析ZooKeeper的實現原理

ZooKeeper的由來

主要是解決分佈式環境下的服務協調問題而產生的，實現ZooKeeper須要作什麼？

• 防止單點故障
  • 因此這個中間件須要考慮到集羣,並且這個集羣還須要分攤客戶端的請求流量
• 集羣存在數據同步和leader節點
• 如何選舉leader節點，leader掛了後的數據恢復
  • ZooKeeper基於paxos協議衍生出了ZAB協議
• leader節點如何保持和別的節點的數據一致性，並且是強一致
  • 分佈式事務：2PC、3PC

2PC提交

• 分佈式事務爲了保持事務的ACID，須要引入協調者（TM）、被調度這（AP）
• 全部事務分兩個階段提交，因此叫作二階段提交
  1. 投票階段（所有yes，才能提交，有一個no就須要全不會滾）
  2. 執行事務階段

ZooKeeper採起的是類2PC的策略

• 客戶端隨機連入ZooKeeper集羣，
  • 若是是讀請求，直接讀取；
  • 若是是寫請求，轉發給leader提交事務，
  • leader廣播事務，只須要超過一半的節點回復yes 就可提交

• leader角色兩個任務：
  • 事務請求的惟一調度者和處理者，保證集羣事務處理的順序性
  • 集羣內部各個服務器的調度者
• Follower 角色任務
  • 處理客戶端非事務請求，轉發事務請求給leader
  • 參與leader發起的事務提交投票，超過半數統一leader才能commit
• observer角色任務
  • ZooKeeper3.3引進的
  • 觀察ZooKeeper集羣最新變化狀態，而且同步套本身服務器上
  • 不參與一切投票：包括事務投票和leader選舉
  • 僅僅提供非事務服務，在不影響集羣事務處理能力的前提下，提高非事務處理能力
• 集羣組成
  • 集羣存在幾臺機器你們都知道，互相知道彼此
  • ZooKeeper採用2n+1 server提供服務，最多容許n臺掛掉
    • 舉例：5臺機器，最多容許掛2臺；6臺機器也是最多容許掛2臺
    • 所以，5臺6臺容災性差很少，6臺反而增長了網絡負擔
    • 採起2n+1的緣由

ZAB協議

• 支持崩潰恢復的原子廣播協議
• 集羣啓動或leader網絡中斷（與半數以上Follower斷開鏈接）時，ZAB協議進入崩潰恢復模式
• 當集羣選舉出新的leader，而且過半數節點和leader保持數據同步的時候，進入消息廣播模式（退出崩潰恢復模式）
• leader節點正常，新節點加入，或Follower故障恢復後，進入數據恢復模式進行數據同步
  • 同步完成後纔可對外提供非事務服務

消息廣播是一個簡化版本的2PC：

• leader接收到消息請求後，賦予消息全劇惟一自增id（zxid）
  • 經過zxid 來實現因果有序
• leader爲每一個Follower準備了一個FIFO的隊列（tcp協議實現，以實現全局有序這一特色）
  • 將帶有zxid的消息做爲提案（proposal）分發給每個Follower
  • Follower接收到proposal後，寫入磁盤，再向leader回覆ack
  • leader 收到半數以上ACK後，會向Follower發送commit，而且本地提交
  • 當Follower收到commit之後會提交該消息

崩潰恢復模式須要解決的問題

• 已經處理的消息不能丟失
• 被丟棄的消息不能再次出現
  • leader生成proposal後就掛掉，其餘Follower沒有收到，該proposal被新leader跳過，
  • 老的leader恢復後（從新接入後變成Follower），保留了該proposal，不該該發出去，應該刪掉

崩潰恢復模式須要知足：

• leader選舉算法，新選出來的leader具備全部proposal最大zxid
  • 就能保證其具備全部已提交的事務
• 生成的zxid 比以前的都大
  • zxid 是64位，高32位是epoch編號，低32位是消息計數器
  • 新選舉leader會epoch+1，低32位重置爲0
  • 當老的leader從新接入，新的leader會讓其將全部擁有舊的epoch，未被commit的老的proposal清除

leader選舉

• 服務器啓動時的leader選舉
  • 每一個server發出一個投票給其餘機器
    • 都是先將本身做爲leader進行投票
    • 投票內容帶上本身的myid、zxid
  • 接收各個服務器投票
    • 檢查是不是本輪投票，是否來自looking狀態服務器
  • 處理投票
    • pk本人投票和接收到的其餘投票
    • 優先比較zxid，取大的；再比較myid，取大的
    • 將pk出的新的投票信息發出去
  • 統計投票
    • 每次投票後，都會統計投票結果，判斷是否有過半數相同的投票信息
  • 改變服務器狀態
    • 若是是Follower 狀態改成following
    • leader 改成leading
• 運行過程當中的leader選舉
  • 變動狀態
    • 非observer 都改狀態爲looking，開啓leader選舉
  • 每一個server發出投票
  • 處理投票
  • 統計投票
  • 修改狀態

leader選舉源碼分析

• 在3.4.0後的Zookeeper的版本只保留了TCP版本的FastLeaderElection選舉算法
• 當一臺機器進入Leader選舉時，當前集羣可能會處於如下兩種狀態：

  • 集羣中已經存在Leader

  • 集羣中不存在Leader

• 對於集羣中已經存在Leader而言，此種狀況通常都是某臺機器啓動得較晚，在其啓動以前，集羣已經在正常工做，對這種狀況，該機器試圖去選舉Leader時，會被告知當前服務器的Leader信息，對於該機器而言，僅僅須要和Leader機器創建起鏈接，並進行狀態同步便可。

Leader選舉實現細節

• 服務器具備四種狀態，分別是LOOKING、FOLLOWING、LEADING、OBSERVING。
  • LOOKING：尋找Leader狀態。當服務器處於該狀態時，它會認爲當前集羣中沒有Leader，所以須要進入Leader選舉狀態。
  • FOLLOWING：跟隨者狀態。代表當前服務器角色是Follower。
  • LEADING：領導者狀態。代表當前服務器角色是Leader。
  • OBSERVING：觀察者狀態。代表當前服務器角色是Observer。
• 投票數據結構
  • 每一個投票中包含了兩個最基本的信息，所推舉服務器的SID和ZXID，投票（Vote）在Zookeeper中包含字段以下：

    • id：被推舉的Leader的SID。

    • zxid：被推舉的Leader事務ID。

    • electionEpoch：邏輯時鐘，用來判斷多個投票是否在同一輪選舉週期中，

      • 該值在服務端是一個自增序列，每次進入新一輪的投票後，都會對該值進行加1操做。

    • peerEpoch：被推舉的Leader的epoch。

    • state：當前服務器的狀態。

• 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)。

    • 爲了不兩臺機器之間重複地建立TCP鏈接，Zookeeper只容許SID大的服務器主動和其餘機器創建鏈接，不然斷開鏈接。

    • 一旦鏈接創建，就會根據遠程服務器的SID來建立相應的消息發送器SendWorker和消息接收器RecvWorker，並啓動。

  • (3) 消息接收與發送。

    • 消息接收：由消息接收器RecvWorker負責，因爲Zookeeper爲每一個遠程服務器都分配一個單獨的RecvWorker，

      • 所以，每一個RecvWorker只須要不斷地從這個TCP鏈接中讀取消息，並將其保存到recvQueue隊列中。

    • 消息發送：因爲Zookeeper爲每一個遠程服務器都分配一個單獨的SendWorker，

      • 所以，每一個SendWorker只須要不斷地從對應的消息發送隊列中獲取出一個消息發送便可，同時將這個消息放入lastMessageSent中。

• 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選舉產生。