也可以在我的個人網站中查看該文章?02-Zookeeper理論相關——Paxos和ZAB
文章目錄
02-Zookeeper理論相關——Paxos和ZAB
攘其外必先安其內
Paxos和ZAB
Paxos算法
關於Paxos算法相關介紹和講解的可以看上面鏈接的文章，通俗易懂，去看完再看該篇剩下的。
ZAB協議
- 事實上，zk並沒有完全採用Paxos 算法，而是使用了Zookeeper Atomic Broadcast即zookeeper原子廣播協議作爲其數據一致的核心算法。
- ZAB是爲zk專門設計的支持崩崩潰恢復的原子廣播。
- zk主要依賴ZAB協議來實現分佈式數據的一致性。基於該協議，zk實現了一種主備模式的系統架構來保持集羣中各副本之間數據的一致性。
- 具體的，zk使用一個單一的主進程來接收並處理client的所有事務請求，並採用ZAB原子廣播協議，將server數據的狀態變更爲事務 Proposa(提案)的形式廣播到所有的副本進程上。
- 順序性：由於順序執行的狀態變更前後會存在一定的依賴關係，ZAB協議需要保證保證若一個狀態變更被處理時，所有其依賴的狀態變更都應該已經被處理了。
- 高可用性：考慮到主進程可能崩潰，ZAB協議還需要在主進程崩潰時保持正常工作。
協議介紹
- ZAB協議包括兩種基本的模式，分別是崩潰恢復和消息廣播。
- 當整個服務框架在啓動過程中，或是當leader服務器出現網絡中斷、崩潰退出與重啓等異常情況時，ZAB協議就會進入恢復模式並選舉產生新的leader服務器。當選舉產生了新的leader服務器，同時集羣中已有過半的機器(follwoer)與leader完成狀態同步(即數據同步，用以保證集羣中存在過半的機器與leader的數據狀態保持一致)後，退出恢復模式。
- 過半機器同步完成後，整個服務框架就可以進入消息廣播模式了。啓動後新加入的機器會自覺進入數據恢復模式(即找到leader並進行數據同步)。
- leader server是唯一允許處理事務請求的機器，若其他機器接收到client的事務請求，會將該請求轉發給leader；接着，leader會生成相應的事務提案併發起一輪廣播協議。
消息廣播
- ZAB協議的消息廣播過程使用的是一個原子廣播協議，類似於一個二階段提交過程。
- 當過半的follower反饋ack之後就可以提交事務Proposal(提案)了。
- 但是該模型無法處理leader崩潰退出而帶來的數據不一致問題。因此，在ZAB協議中添加了另一模式，即採用崩潰恢復模式來解決這個問題。
- 另外，整個消息廣播協議是基於具有FIFO特性的TCP協議來進行網絡通信的，因此能夠很容易地保證消息廣播過程中消息接收與發送的順序性。(zk採用單一主線程來處理client請求)
- 在整個消息廣播中，leader服務器會爲每個事物請求生成對應的Proposal(提案)來進行廣播，並且在廣播事物Proposal之前，爲Proposal分配一個全局單調遞增的唯一ID，即事物ID(ZXID)。
- 具體而言，在消息廣播過程中，leader server會爲每個follower分配一個單獨的隊列，然後將需要廣播的事務proposal依次放入這些隊列中，並且根據FIFO策略發送消息。每個follower接收到proposal後，會首先將其以事務日誌形式寫入本地磁盤，並且在成功寫入後(ack)反饋給leader。當leader收到超過半數的ack後，會廣播一個commit消息給所有的follower以通知其進行事務提交，同時leader自身也會完成對事務的提交，爾follower也會在接收到commit消息後，完成對事務的提交。(提交至內存)
整個消息廣播流程本質上是一個2PC(兩階段提交)過程：
- leader發送事務proposal --> follower將proposal以事務形式寫入本地磁盤，並且反饋ack給leader。
- leader在收到半數ack後，會廣播一個commit消息給所有follower --> leader完成事務提交 --> follower完成事務的提交。
崩潰恢復
當leader崩潰或者leader是去大多數的follower，這時候zk進入恢復模式，恢復模式需要重新選舉一個新的leader，讓所有的server都恢復到一個正確的狀態。
zk的選舉算法有兩種：一種是基於basic paxos實現的，另外一種是基於fast paxos實現的。系統默認的選舉算法是fast paxos。
zookeeper選主流程(basic paxos)
- 選舉線程由當前server發起選舉的線程擔任，其主要功能是對投票結果進行統計，並選出推薦的server；
- 選舉線程首先向所有server發起一次詢問(包括自己)；
- 選舉線程收到回覆後，驗證是否是自己發起的詢問(驗證zxid是否一致)，然後獲取對方的id(myid)，並存儲到當前詢問對象列表中，最後獲取對方提議的leader相關信息(id,zxid)，並將這些信息存儲到當次選舉的投票記錄表中；
- 收到所喲偶server回覆後，就計算出zxid最大的那個server，並將這個server相關信息設置成下一次要投票的server；
- 線程將當前zxid最大的server設置爲當前server要推薦的leader，如果此時獲勝的server獲得(n/2 + 1)的server票數，設置當前推薦的leader爲獲勝的server，將根據獲勝的server相關信息設置自己的狀態，否則，繼續這個過程，直到leader被選舉出來。
- 要使leader獲得多數server的支持，則server總數必須是奇數 2n+1，且存活的server的數目不得少於 n+1，每個server啓動後都會重複以上流程。在恢復模式下，如果是剛從崩潰狀態恢復的或者剛啓動的server還會從磁盤快照中恢復數據和會話信息，zk會記錄事務日誌並定期進行快照，方便在恢復時進行狀態恢復。
zookeeper選主流程(fast paxos)
fast paxos流程是在選舉過程中，某server首先向所有server提議自己要成爲leader，當其他server收到提議後，解決epoch和zxid的衝突，並接受對方的提議，然後向對方發送接受提議完成的消息，重複這個流程，最後一定能選舉出leader。
數據同步
- 完成leader選舉後，在正式開始工作(即接收客戶端的事務請求，然後提出新的提案)之前，leader server會首先確認事務日誌中的所有proposal是否都已經被集羣中過半的機器提交了，即是否完成數據同步。
- ZAB協議的數據同步過程：
- 首先，leader需要確保所有follower能夠接收到每一條proposal，並且能正確地將所有已提交的proposal應用到內存數據庫中。
- leader爲每個follower準備一個隊列，並將未被各follower同步的事務以proposal消息的形式逐個發送給follower，並在每個proposal後緊接着一個commit消息，表明該事務已提交。
- 等到follower將其所有尚未同步的事務proposal都從leader上同步過來併成功應用到本地數據庫中後，leader會將follower加入到真正的可用follower列表中。
- 首先，leader需要確保所有follower能夠接收到每一條proposal，並且能正確地將所有已提交的proposal應用到內存數據庫中。
- 還需要考慮如何處理那些需要被丟棄的事務proposal：
- ZAB的事務編號ZXID被設計爲一個64位的數字，其中低32位可以看做一個簡單的單調遞增的計數器，leader在產生一個新的proposal時，都會加 1；而高32位則代表了leader週期epoch(時代)的編號，每當產生一個新的leader，就會從這個leader上取出本地日誌最大事務proposal的ZXID，並從該ZXID中解析出對象的epoch值，然後加1作爲新的epoch(時代)，並將低32位置位0來開始生成新的ZXID。從而，ZAB協議可以通過epoch編號來區分leader週期變化的策略，有效避免不同的leader錯誤地使用相同的ZXID編號提出不一樣的proposal的異常情況。
- 基於這樣的策略，當一個包含了上一個leader週期中尚未提交的proposal的server啓動時肯定無法成爲leader，因爲其不可能擁有最高ZXID的proposal。那麼該server會成爲follower，當其連接上leader後，會被leader要求進行回退操作，即回退到一個確實已經被集羣中過半機器提交的最新的proposal。
小結
zookeeper工作原理
zookeeper的核心是原子廣播，這個機制保證了各個server之間的同步。實現這個機制的協議叫做ZAB協議。ZAB協議有兩種模式，它們分別是恢復模式(選主)和廣播模式(同步)。當服務啓動或者在領導者崩潰後，ZAB就進入了恢復模式，當領導者被選舉出來，且大多數server完成了和leader的狀態同步後，恢復模式就結束了。狀態同步保證了leader和server具有相同的系統狀態。
爲了保證事務的順序一致性，zookeeper採用了遞增的事務id號(zxid)來標識事務。所有的提議(proposal)都在被提出時加上了zxid。實現中zxid是一個64位的數字，它高32位是epoch用來標識leader關係是否改變，每次一個leader被選出來，它都會有一個新的epoch，標識當前屬於哪個leader的統治時期。低32位用於遞增計數。