zab協議 的全稱是zookeeper atomic broadcast（zookeeper原子廣播），zookeeper 是通過 zab 協議來保證分布式事務的最終一致性。zab協議是為分布式協調服務zookeeper專門設計的一種支援崩潰恢復的原子廣播協議，是zookeeper保證資料一致性的核心演算法。
zab借鑑了paxos演算法，但又不像paxos那樣，是一種通用的分布式一致性演算法。它是特別為zookeeper設計的支援崩潰恢復的原子廣播協議。在zookeeper中主要依賴zab協議來實現資料一致性，基於該協議，zk實現了一種主備模型（即leader和follower模型）的系統架構來保證集群中各個副本之間資料的一致性。
這裡的主備系統架構模型，就是指只有一台客戶端（leader）負責處理外部的寫事務請求，然後leader客戶端將資料同步到其他follower節點。zookeeper 客戶端會隨機的鏈結到 zookeeper 集群中的乙個節點，如果是讀請求，就直接從當前節點中讀取資料；如果是寫請求，那麼節點就會向 leader 提交事務，leader 接收到事務提交，會廣播該事務，只要超過半數節點寫入成功，該事務就會被提交。
所有的事務請求必須由乙個全域性唯一的伺服器來協調處理，這樣的伺服器被叫做leader伺服器。其他剩餘的伺服器則是follower伺服器。
leader伺服器 負責將乙個客戶端事務請求，轉換成乙個事務proposal，並將該 proposal 分發給集群中所有的 follower 伺服器，也就是向所有 follower 節點傳送資料廣播請求（或資料複製）
分發之後leader伺服器需要等待所有follower伺服器的反饋（ack請求），在zab協議中，只要超過半數的follower伺服器進行了正確的反饋後（也就是收到半數以上的follower的ack請求），那麼 leader 就會再次向所有的 follower伺服器傳送 commit 訊息，要求其將上乙個事務proposal 進行提交。
整個集群啟動過程中，或者當 leader 伺服器出現網路中弄斷、崩潰退出或重啟等異常時，zab協議就會進入崩潰恢復模式，選舉產生新的leader，同時集群中 leader 伺服器開始資料同步。
leader選舉規則
新選舉出來的 leader 不能包含未提交的 proposal，新選舉的 leader 必須都是已經提交了 proposal 的 follower 伺服器節點。
新選舉的 leader 節點中含有最大的 zxid。避免 leader 伺服器檢查 proposal 的提交和丟棄工作。
資料同步
完成 leader 選舉後（新的 leader 具有最高的zxid），在正式開始工作之前（接收事務請求，然後提出新的 proposal），leader 伺服器會首先確認事務日誌中的所有的 proposal 是否已經被集群中過半的伺服器 commit。
leader 伺服器需要確保所有的 follower 伺服器能夠接收到每一條事務的 proposal ，並且能將所有已經提交的事務 proposal 應用到記憶體資料中。等到 follower 將所有尚未同步的事務 proposal 都從 leader 伺服器上同步過啦並且應用到記憶體資料中以後，leader 才會把該 follower 加入到真正可用的 follower 列表中。
丟棄proposal
在 zab 的事務編號 zxid 設計中，zxid是乙個64位的數字。其中低32位可以看成乙個簡單的單增計數器，針對客戶端每乙個事務請求，leader 在產生新的 proposal 事務時，都會對該計數器加1。而高32位則代表了 leader 週期的 epoch 編號。
epoch 編號可以理解為當前集群所處的年代，或者週期。每次leader變更之後都會在 epoch 的基礎上加1，這樣舊的 leader 崩潰恢復之後，其他follower 也不會聽它的了，因為 follower 只服從epoch最高的 leader 命令。
每當選舉產生乙個新的 leader ，就會從這個 leader 伺服器上取出本地事務日誌充最大編號 proposal 的 zxid，並從 zxid 中解析得到對應的 epoch 編號，然後再對其加1，之後該編號就作為新的 epoch 值，並將低32位數字歸零，由0開始重新生成zxid。
zab 協議通過 epoch 編號來區分 leader 變化週期，能夠有效避免不同的 leader 錯誤的使用了相同的 zxid 編號提出了不一樣的 proposal 的異常情況。
當乙個包含了上乙個 leader 週期中尚未提交過的事務 proposal 的伺服器啟動時，當這台機器加入集群中，以 follower 角色連上 leader 伺服器後，leader 伺服器會根據自己伺服器上最後提交的 proposal 來和 follower 伺服器的 proposal 進行比對，比對的結果肯定是 leader 要求 follower 進行乙個回退操作，回退到乙個確實已經被集群中過半機器 commit 的最新 proposal。
當選舉產生了新的 leader，同時集群中有過半的機器與該 leader 伺服器完成了狀態同步（即資料同步）之後，zab協議就會退出崩潰恢復模式，進入訊息廣播模式。
zab協議中 leader 等待 follower 的ack反饋訊息是指「只要半數以上的follower成功反饋即可，不需要收到全部follower反饋」。
只要有一台伺服器提交了 proposal，就要確保所有的伺服器最終都能正確提交 proposal。這也是 cap/base 實現最終一致性的乙個體現。
leader 伺服器與每乙個 follower 伺服器之間都維護了乙個單獨的 fifo 訊息佇列進行收發訊息，使用佇列訊息可以做到非同步解耦。 leader 和 follower 之間只需要往佇列中發訊息即可。如果使用同步的方式會引起阻塞，效能要下降很多。
具體步驟
客戶端發起乙個寫操作請求。
leader 伺服器將客戶端的請求轉化為事務 proposal 提案，同時為每個 proposal 分配乙個全域性的id，即zxid。
leader 伺服器為每個 follower 伺服器分配乙個單獨的佇列，然後將需要廣播的 proposal 依次放到佇列中取，並且根據 fifo 策略進行訊息傳送。
follower 接收到 proposal 後，會首先將其以事務日誌的方式寫入本地磁碟中，寫入成功後向 leader 反饋乙個 ack 響應訊息。
leader 接收到超過半數以上 follower 的 ack 響應訊息後，即認為訊息傳送成功，可以傳送 commit 訊息。
leader 向所有 follower 廣播 commit 訊息，同時自身也會完成事務提交。follower 接收到 commit 訊息後，會將上一條事務提交。
當乙個包含了上乙個 leader 週期中尚未提交過的事務 proposal 的伺服器啟動時，當這台機器加入集群中，以 follower 角色連上 leader 伺服器後，leader 伺服器會根據自己伺服器上最後提交的 proposal 來和 follower 伺服器的 proposal 進行比對，比對的結果肯定是 leader 要求 follower 進行乙個回退操作，回退到乙個確實已經被集群中過半機器 commit 的最新 proposal。
節點在一開始都處於選舉節點，只要有乙個節點得到超過半數節點的票數，它就可以當選準 leader（只有到達同步階段，這個準 leader 才會成為真正的 leader）
zookeeper 規定所有有效的投票都必須在同乙個輪次中，每個伺服器在開始新一輪投票時，都會對自己維護的 logicalclock 進行自增操作。
每個伺服器在廣播自己的選票前，會將自己的投票箱（recvset）清空。該投票箱記錄了所受到的選票。例如：server_2 投票給 server_3，server_3 投票給 server_1，則server_1的投票箱為(2,3)、(3,1)、(1,1)。（每個伺服器都會預設給自己投票）
前乙個數字表示投票者，後乙個數字表示被選舉者。票箱中只會記錄每乙個投票者的最後一次投票記錄，如果投票者更新自己的選票，則其他伺服器收到該新選票後會在自己的票箱中更新該伺服器的選票。這一階段的目的就是為了選出乙個準 leader ，然後進入下乙個階段。
followers 和上一輪選舉出的準 leader 進行通訊，同步 followers 最近接收的事務 proposal 。乙個 follower 只會連線乙個 leader，如果乙個 follower 節點認為另乙個 follower 節點，則會在嘗試連線時被拒絕。被拒絕之後，該節點就會進入 leader election階段。
這個階段的主要目的是發現當前大多數節點接收的最新 proposal，並且準 leader 生成新的 epoch ，讓 followers 接收，更新它們的 acceptedepoch。
同步階段主要是利用 leader 前一階段獲得的最新 proposal 歷史，同步集群中所有的副本。
只有當 quorum（超過半數的節點） 都同步完成，準 leader 才會成為真正的 leader。follower 只會接收 zxid 比自己 lastzxid 大的 proposal。
到了這個階段，zookeeper 集群才能正式對外提供事務服務，並且 leader 可以進行訊息廣播。同時，如果有新的節點加入，還需要對新節點進行同步。
zookeeper 順序一致性
zookeeper的一致性保證在順序一致性和線性一致性之間。寫操作在zookeeper中是線性化的，換句話說，在客戶機發出請求和接收相應響應之間的某個時間點上，每次寫操作都會自動生效。這意味著zookeeper中所有客戶端執行的寫操作可以完全按照這樣一種方式進行排序，即這些寫操作的實時排序 zook...
一致性協議
節點在進行事務處理過程中保持原子性和一致性而設計的一種演算法。1.事務詢問。2.執行事務。3.各參與者向協調者反饋事務詢問的響應。理解 類似協調者組織各參與者對一次事務操作進行投票表態的過程。假如參與者全部反饋yes 1.傳送提交請求 2.事務提交 3.反饋事務提交結果 4.完成事務。假如任何乙個參...
一致性協議
在分布式系統中，每乙個機器節點雖然都能夠明確地知道自己在進行事務操作過程中的結果是成功或失敗，但卻無也直接獲取到其他分布式節點的操作結果。因此，當乙個事務操作需要跨越多個分布式節點的時候，為了保持事務處理的acid特性，就需要引人乙個稱為 協調者 的元件來統一排程所有分布式節點的執行邏輯，這些被排程...