一致性
簡述
一致性，是指對每個節點一個數據的更新，整個集羣都知道更新，並且是一致的。假設一個具有N個節點的分佈式系統，當其滿足以下條件時，我們說這個系統滿足一致性：
- 全認同: 所有N個節點都認同一個結果
- 值合法: 該結果必須由N個節點中的過半節點提出
- 可結束: 決議過程在一定時間內結束，不會無休止地進行下去
面臨着的問題
- 消息傳遞異步無序: 現實網絡不是一個可靠的信道，存在消息延時、丟失，節點間消息傳遞做不到同步有序
- 節點宕機: 節點持續宕機，不會恢復
- 節點宕機恢復: 節點宕機一段時間後恢復，在分佈式系統中最常見
- 網絡分化: 網絡鏈路出現問題，將N個節點隔離成多個部分
- 拜占庭將軍問題: 節點或宕機或邏輯失敗，甚至不按套路出牌拋出干擾決議的信息
如下形象demo：
週五
我：晚上下班喫雞
週六凌晨
xc：好的 // 消息延遲
我：WC
---------------------------------
我：晚上下班喫雞
xc：No
(兩小時後)
xc：No problem！ // 宕機節點恢復
我：WC
---------------------------------
我：晚上下班喫雞
... // 節點宕機
---------------------------------
我：晚上下班喫雞
cx:好，我們去大保健！ // 拜占庭將軍
我：WC
前面 已經討論過，在分佈式環境下，有很多不確定性因素，故障隨時都回發生，也講了CAP理論，BASE理論。我們希望達到在分佈式環境下能搭建一個高可用的，且數據高一致性的服務，目標是這樣，但CAP理論告訴我們要達到這樣的理想環境是不可能的。這三者最多完全滿足2個。
在這個前提下，P（分區容錯性）是必然要滿足的，因爲畢竟是分佈式，不能把所有的應用全放到一個服務器裏面，這樣服務器是喫不消的，而且也存在單點故障問題。
所以，只能從一致性和可用性中找平衡。
怎麼個平衡法？在這種環境下出現了BASE理論：
即使無法做到強一致性，但分佈式系統可以根據自己的業務特點，採用適當的方式來使系統達到最終的一致性；
BASE由Basically Avaliable 基本可用、Soft state 軟狀態、Eventually consistent 最終一致性組成，一句話概括就是：平時系統要求是基本可用，除開成功失敗，運行有可容忍的延遲狀態，但是，無論如何經過一段時間的延遲後系統最終必須達成數據是一致的。
其實可能發現不管是CAP理論，還是BASE理論，他們都是理論，這些理論是需要算法來實現的，今天講的2PC、3PC、Paxos算法，ZAB算法就是幹這事情。
所以今天要講的這些的前提一定是分佈式，解決的問題全部都是在分佈式環境下，怎麼讓系統儘可能的高可用，而且數據能最終能達到一致。
2PC
2PC(tow phase commit)兩階段提交。它本身是一致強一致性算法，所謂的兩個階段是指：
第一階段：準備階段(投票階段)
第二階段：提交階段(執行階段)。
我們將提議的節點稱爲協調者(coordinator)，其他參與決議節點稱爲參與者(participants, 或cohorts)。
階段1
在階段1中，協調者發起一個提議，分別問詢各參與者是否接受，如下圖：
階段2
在階段2中，協調者根據參與者的反饋，提交或中止事務，如果參與者全部同意則提交，只要有一個參與者不同意就中止。如下圖：
實例
下面我們通過一個例子來說明兩階段提交協議的工作過程：
A組織B、C和D三個人去爬山：如果所有人都同意去爬山，那麼活動將舉行；如果有一人不同意去爬山，那麼活動將取消。用 2PC 算法解決該問題的過程如下：
首先A將成爲該活動的協調者，B、C和D將成爲該活動的參與者。
階段1：
- A發郵件給B、C和D，提出下週三去爬山，問是否同意。那麼此時A需要
等待B、C和D的郵件。- B、C和D分別查看自己的日程安排表。B、C發現自己在當日沒有活動安排，則發郵件告訴A它們同意下週三去爬山。由於某種原因， D白天沒有查看郵 件。那麼此時A、B和C均
需要等待。到晚上的時候，D發現了A的郵件，然後查看日程安排，發現週三當天已經有別的安排，那麼D回覆A說活動取消吧。
階段2：
- 此時A收到了所有活動參與者的郵件，並且A發現D下週三不能去爬山。那麼A將發郵件通知B、C和D，下週三爬山活動取消。
- 此時B、C回覆A太可惜了，D回覆A不好意思。至此該事務終止。
數據庫中的2PC
在innodb存儲引擎，對數據庫的修改都會寫到undo和redo中，不只是數據庫，很多需要事務支持的都會用到這個思路。
對一條數據的修改操作首先寫undo日誌，記錄的數據原來的樣子，接下來執行事務修改操作，把數據寫到redo日誌裏面，萬一捅婁子，事務失敗了，可從undo裏面回覆數據。
不只是數據庫，在很多企業裏面，比如華爲等提交數據庫修改都回要求這樣，你要新增一個字段，首先要把修改數據庫的字段SQL提交給DBA（redo），這不夠，還需要把刪除你提交字段，把數據還原成你修改之前的語句也一併提交者叫（undo）
數據庫通過undo與redo能保證數據的強一致性，要解決分佈式事務的前提就是當個節點是支持事務的。
這在個前提下，2pc借鑑這失效，首先把整個分佈式事務分兩節點，首先第一階段叫準備節點，事務的請求都發送給一個個的資源，這裏的資源可以是數據庫，也可以是其他支持事務的框架，他們會分別執行自己的事務，寫日誌到undo與redo，但是不提交事務。
當事務管理器收到了所以資源的反饋，事務都執行沒報錯後，事務管理器再發送commit指令讓資源把事務提交，一旦發現任何一個資源在準備階段沒有執行成功，事務管理器會發送rollback，讓所有的資源都回滾。這就是2pc，非常非常簡單。
說他是強一致性的是他需要保證任何一個資源都成功，整個分佈式事務才成功。
優缺點
在異步環境並且沒有節點宕機的模型下，2PC可以滿足全認同、值合法、可結束，是解決一致性問題的一種協議。從協調者接收到一次事務請求、發起提議到事務完成，經過2PC協議後增加了2次RTT(propose+commit)，帶來的時延增加相對較少。
優點：
優點：原理簡單，實現方便
缺點：
缺點：
同步阻塞，單點問題，數據不一致，容錯性不好
- 同步阻塞
在二階段提交的過程中，所有的節點都在等待其他節點的響應，無法進行其他操作。這種同步阻塞極大的限制了分佈式系統的性能。
- 單點問題
協調者在整個二階段提交過程中很重要，如果協調者在提交階段出現問題，那麼整個流程將無法運轉。更重要的是，其他參與者將會處於一直鎖定事務資源的狀態中，而無法繼續完成事務操作。
- 數據不一致
假設當協調者向所有的參與者發送commit請求之後，發生了局部網絡異常，或者是協調者在尚未發送完所有 commit請求之前自身發生了崩潰，導致最終只有部分參與者收到了commit請求。這將導致嚴重的數據不一致問題。
- 容錯性不好
二階段提交協議沒有設計較爲完善的容錯機制，任意一個節點是失敗都會導致整個事務的失敗。
3PC
三階段提交（Three-phase commit），是二階段提交（2PC）的改進版本。與兩階段提交不同的是，三階段提交有兩個改動點。
引入超時機制。同時在協調者和參與者中都引入超時機制。- 在第一階段和第二階段中插入一個
準備階段。保證了在最後提交階段之前各參與節點的狀態是一致的。也就是說，除了引入超時機制之外，3PC把2PC的準備階段再次一分爲二，這樣三階段提交就有CanCommit、PreCommit、DoCommit三個階段。
第一階段canCommit
3PC的CanCommit階段其實和2PC的準備階段很像。協調者向參與者發送commit請求，參與者如果可以提交就返回Yes響應，否則返回No響應。
1.
事務詢問協調者向參與者發送CanCommit請求。詢問是否可以執行事務提交操作。然後開始等待參與者的響應。
2.響應反饋參與者接到CanCommit請求之後，正常情況下，如果其自身認爲可以順利執行事務，則返回Yes響應，並進入預備狀態。否則反饋No
第二階段PreCommit
協調者根據參與者的反應情況來決定是否可以記性事務的PreCommit操作。根據響應情況，有以下兩種可能。
假如協調者從所有的參與者獲得的反饋都是Yes響應，那麼就會執行事務的預執行。
- 發送預提交請求 協調者向參與者發送PreCommit請求，並進入Prepared階段。
- 事務預提交 參與者接收到PreCommit請求後，會執行事務操作，並將undo和redo信息記錄到事務日誌中。
- 響應反饋 如果參與者成功的執行了事務操作，則返回ACK響應，同時開始等待最終指令。
假如有任何一個參與者向協調者發送了No響應，或者等待超時之後，協調者都沒有接到參與者的響應，那麼就執行事務的中斷。
發送中斷請求 協調者向所有參與者發送abort請求。
中斷事務 參與者收到來自協調者的abort請求之後（或超時之後，仍未收到協調者的請求），執行事務的中斷。
第三階段doCommit
該階段進行真正的事務提交，也可以分爲以下兩種情況。
執行提交
發送提交請求協調接收到參與者發送的ACK響應，那麼他將從預提交狀態進入到提交狀態。並向所有參與者發送doCommit請求。事務提交參與者接收到doCommit請求之後，執行正式的事務提交。並在完成事務提交之後釋放所有事務資源。響應反饋事務提交完之後，向協調者發送Ack響應。完成事務協調者接收到所有參與者的ack響應之後，完成事務。
中斷事務
協調者沒有接收到參與者發送的ACK響應（可能是接受者發送的不是ACK響應，也可能響應超時），那麼就會執行中斷事務。
- 發送中斷請求 協調者向所有參與者發送abort請求
- 事務回滾 參與者接收到abort請求之後，利用其在階段二記錄的undo信息來執行事務的回滾操作，並在完成回滾之後釋放所有的事務資源。
- 反饋結果 參與者完成事務回滾之後，向協調者發送ACK消息
- 中斷事務 協調者接收到參與者反饋的ACK消息之後，執行事務的中斷。
所有數據庫的分佈式事務一般都是二階段提交，而這三階段的思想更多的被借鑑擴散成其他的算法。
優缺點
與2PC區別：
第二階段才寫undo和redo事務日誌
第三階段協調者出現異常或網絡超時參與者也會commit
優點：
改善同步阻塞
改善單點故障
缺點：
同步阻塞
單點故障
數據不一致
容錯機制不完善
Paxos算法
這算法的提出者萊斯利·蘭伯特在前面幾篇論文中都不是以嚴謹的數學公式進行的。其實這個paxos算法也分成兩階段。首先這個圖有2個角色，提議者與接收者。
第一階段
提議者對接收者吼了一嗓子，我有個事情要告訴你們，當然這裏接受者不只一個(一半要奇數個)，它也是個分佈式集相當於星期一開早會，可恥的領導吼了句：“要開會了啊，我要公佈一個編號爲001的提案，收到請回復”。這個時候領導就會等着，等員工回覆1“好的”，如果回覆的數目超過一半，就會進行下一步。如果由於某些原因（接收者死機，網絡問題，本身業務問題），導致通過的協議未超過一半，
這個時候的領導又會再吼一嗓子，當然氣勢沒那兇殘：“好了，怕了你們了，我要公佈一個新的編號爲002的提案，收到請回復1”【其實和上學時候老師講課很像，老師經常問聽懂了嗎？聽懂的回1，沒懂的回2，只有回覆1的佔了大多數，才能講下個知識點】
第二階段
接下來到第二階段，領導苦口婆心的把你們叫來開會了，今天編號002提案的內容是：“由於項目緊張，今天加班到12點，同意的請舉手”這個時候如果絕大多少的接收者都同意，那麼好，議案就這麼決定了，如果員工反對或者直接奪門而去，那麼領導又只能從第一個階段開始：“大哥，大姐們，我有個新的提案003，快回會議室吧。。”
paxos的核心就是少數服從多數。
苦逼的領導（單點問題）：有這一幫兇殘的下屬，這領導要不可能被氣死，要不也會辭職，這是單點問題。
凶神惡煞的下屬（一致性問題）：如果員工一直都拒絕，故意和領導擡杆，最終要產生一個一致性的解決方案是不可能的。
所以paxos協議肯定不會只有一個提議者，作爲下屬的員工也不會那麼強勢
協議要求：如果接收者沒有收到過提案編號，他
必須接受第一個提案編號
如果接收者沒有收到過其他協議，他必須接受第一個協議。
一旦一個提議被大家同意，那麼之後的人再次提議，也是無效的，結果必須跟先前被大家接受的一致。
形象解說
Paxos算法解決的問題是在一個可能發生消息延遲、丟失、重複的分佈式系統中如何就某個值達成一致，保證不論發生以上任何異常，都不會破壞決議的一致性。這 個“值”可能是一個數據的某，也可能是一條LOG等；根據不同的應用環境這個“值”也不同。
一個典型的場景是，在一個分佈式數據庫系統中，如果各節點的初始狀態一致，每個節點都執行相同的操作序列，那麼他們最後能得到一個一致的狀態。爲保證每個節點執行相同的命令序列，需要在每一條指令上執行一個一致性算法以保證每個節點看到的指令一致。
例如：公司商定年會舉辦的地點，每個人都可以提出建議。在現實環境中我們可以在一個會議室共同討論或在微信羣中討論（基於內存共享方式）；但在基於消息傳遞的分佈式環境中每個人只能通過手機短信與其它人通過。如何在這種會延遲、丟失的環境中確定一個年會舉辦地點；
Paxos算法是這樣解決這個問題：
1、每個人都可以提出建議、同意建議、接受建議
2、少數服從多數。只要建議被多數人同意即可確定該建議。
於是確定以下討論方式：
1、只有被提出來的建議才能被大家同意。
2、最終只能確定一個建議
3、如果某個人認爲大家同意了某 個建議，那麼這個建議必須真的是被大家同意的
算法推論：
情況一：如果只有一個人提出建議怎麼辦？
如果只有一個建議被提出來那麼大家必須贊同這個建議，因爲如果不同意這個建議就無法確定一個年會舉辦地點。
P1:每一個人必須同意他收到的第一個建議， 基於這樣的結論會出現以下問題：
張三給王五發短信說：我建議去上海舉辦年會！
王五給李四發短信說：我建議去廣州舉辦年會！
李四給張三發短信說：我建議去北京舉辦年會！
根據P1：每個人必須同意他收到的第一個建議，那麼張三、李四、王五最終獲得的信息是不一致的。
所以再次規定：一個提議必須被大多數人同意才能生效。
那麼說明一個人可以同時同意多個建議，如果一個人可以同時同意多個建議最終可能出現拜占庭將軍問題導致最終結果不一致。（例如：張三同意到北京舉辦也同意到廣州舉辦，那麼李四將獲得2票一票自己的，一票張三的。他會認爲自己獲得多數人支持所以就確定最終是到北京舉辦，同理王五也會同時獲得2票，也認爲大家最終決定到廣州舉辦）。 所以要避免出現這種問題，某個人只能同意的多個提議中的內容相同（公司舉辦的地址）就不會出現這種問題。
最終協商結果是有2票是到同一個地方，這樣就可以確認最終舉辦地！
那麼就會引出 這樣的一個結論：一旦同意某個建議，那麼之後同意的建議中提議公司舉辦年會的地址必須一致。
問題出來了：如何確定什麼是之前，什麼 是之後
所以必須爲提議分配一個編號，在提議之間建立一個全序關係。
情況二：
當張三、李四、王五三個人確定最終到鄭州舉辦年會後。趙六、孫七2人由於手機沒電，沒收到通知，當他們2人開機後趙六給孫七發短信提議到海南舉辦，這個提議是孫七開機後第一次收到的提議，根據P1原則，他必須同意他接收到的第一個提議，所以孫七同意到海南舉行年會。但這樣就會導致孫七與張三、李四、王五他們確定的舉辦地點不一致。
爲了避免出現以上問題。對P2進行具體說明：
P2a:一旦一個提議被大家同意，那麼之後的人再次同意的提議中的公司舉辦年會的地址必須一致。
也就是說，孫七在開機後同意的第一個提議必須是“到鄭州舉辦”纔不會出現信息不一致的現象。但孫七開機後必須得接受第一個提議（P1原則），並且無法干涉提議中的內容（公司舉辦年會的地址）。所以最好的辦法通過某種方式讓趙六的提議中的內容與張三、李四同意的地址相同（到鄭州舉行）。這樣孫七同意的第一個提議就是“到鄭州舉辦”
我們再次對P2a進行修改：
P2b:一旦一個提議被大家同意，那麼之後的人再次提議，提議中的公司舉辦年會的地址必須跟之前其它人解決的地址一致。
如何讓剛開機的趙六提議的內容必須與張三、李四、王五討論出來的一致（到鄭州舉行）？
我們繼續對P2b進行強化修改：
P2C:如果有一個編號爲N的提議具有V(提議的內容)，那麼存在一個多數派，要麼他們中所有人都沒有同意編號小於N的任何提議，要麼他們已經同意的所有編號小於N的提案中編號最大的那個提案具有V。
要滿足P2C的要求，提議人在提議之前，首先要和多數人通信並獲得他們進行的最後一次同意的提議。之後根據反饋的信息決定這次提議的內容，形成提議開始投票！
重點
所以整個投票決議分兩個階段：
- 準備階段
1、提議人選擇一個編號N，並將準備信息發送給多數人。
2、如果收信人收到準備消息後，如果提議的編號大於它已經回覆的所有準備信息。那麼收信人將自己上次接受的提議內容回覆給提議人，並承諾不再回復小於N的提議。
- 同意階段
1、當一個提議人收到多數人反饋的信息後，就進入同意階段。它要向反饋給它信息的人再次發送一個請同意該提議的請求。包含編號N和根據P2C決定的提議內容（如果回覆中沒有反饋他們已經接受過的提議內容，則可以自由決定提議內容）
2、在不違背向其它人承諾的前提下，收到該提議請求後立即同意該請求。
假設：只有User1、User2、User3 三個人決定1+1等於幾！
提案階段
- User1 提案編號爲 1 併發送給User2和User3。
因User2 和User3 根據P2c它們並沒有接受過小於編號爲1的提案。所以它們可以接受該提議，並反饋給User1 不再接受小於編號1的提案。這時User1收到多數人的回覆，將進入第2階段。（如果收到的回覆並不能形成多數人，那麼將再次進入階段1）
- User2 提案編號爲2 ；併發送給User1和User3。
因User1第一次收到提案，並且根據P2C它並沒有同意過小於編號爲2的提議，所以它可以接受該提議。User3由於接受過User1編號爲1的提案，但User2的提案編號 2 > 1 所以User3也可以同意User2的提議，並反饋不再接受小於2的提議。User2也收到多數人的回覆，將進行第2階段。
- User3提案編號爲3 ；併發送給user1 和user2 .
因user1收到user3編號爲3的提案 > user2編號爲2的提案，所以接受user3的提案。
因user2收到User3編號爲3的提案 > user1 編號爲1的提案，所以接受user3的提案。
至此user3也收到多數人回覆，將進行第2階段。
同意階段
- user1 發送編號爲1的提議，提議內容爲：1+1=1；併發送給user2和User3 。
由於user2已經聲明不再接受小於3的提案，所以拒絕user1的提案。
由於User3已經聲明不再接受小於2的提案，所以同樣拒絕User1的提案。
User1提議被多數人拒絕，再次`進入階段1**.
- user2 發送編號爲2的提議，提議內容爲：1+1=2；併發送給User1和User3
由於User1已經聲明不再接受小於3的提案，所以拒絕user2的提議。
由於User3已經聲明不再接受小於2的提案，該提案編號=2所以user3同意User2的提議。
但User2並沒有獲得多數人的同意，所以同樣進行階段1.
- User3 發送編號爲3的提議，提議內容爲：1+1=3；併發送給User1和User2;
由於 user1 聲明不再接受小於3的提案，所以同意User3的提議。
由於 user2 聲明不再接受小於3的提案，所以同意User3的提議。
至此最終User3可以獲得多數人的同意。
ZAB
很多人會誤以爲ZAB協議是Paxos的一種特殊實現，事實上他們是兩種不同的協議。ZAB和Paxos最大的不同是，ZAB主要是爲分佈式主備系統設計的，而Paxos的實現是一致性狀態機(state machine replication)
儘管ZAB不是Paxos的實現，但是ZAB也參考了一些Paxos的一些設計思想，比如：
- leader向follows提出提案(proposal)
- leader 需要在達到法定數量(半數以上)的follows確認之後纔會進行commit
- 每一個proposal都有一個紀元(epoch)號，類似於Paxos中的選票(ballot)
ZAB特性
- 一致性保證
可靠提交(Reliable delivery) -如果一個事務 A 被一個server提交(committed)了，那麼它最終一定會被所有的server提交
- 全局有序(Total order)
假設有A、B兩個事務，有一臺server先執行A再執行B，那麼可以保證所有server上A始終都被在B之前執行
- 因果有序(Causal order) -
如果發送者在事務A提交之後再發送B,那麼B必將在A之後執行
- 只要大多數（法定數量）節點啓動，系統就行正常運行
- 當節點下線後重啓，它必須保證能恢復到當前正在執行的事務
ZAB的具體實現
- ZooKeeper由
client、server兩部分構成 - client可以在任何一個
server節點上進行讀操作 - client可以在任何一個
server節點上發起寫請求，非leader節點會把此次寫請求轉發到leader節點上。由leader節點執行 - ZooKeeper使用改編的兩階段提交協議來保證server節點的事務一致性
ZXID
ZooKeeper會爲每一個事務生成一個唯一且遞增長度爲64位的ZXID,ZXID由兩部分組成：低32位表示計數器(counter)和高32位的紀元號(epoch)。epoch爲當前leader在成爲leader的時候生成的，且保證會比前一個leader的epoch大
實際上當新的leader選舉成功後，會拿到當前集羣中最大的一個ZXID(因爲數據最新)，並去除這個ZXID的epoch,並將此epoch進行加1操作，作爲自己的epoch。
歷史隊列(history queue)
每一個follower節點都會有一個先進先出（FIFO)的隊列用來存放收到的事務請求，保證執行事務的順序
- 可靠提交由ZAB的事務一致性協議保證
- 全局有序由TCP協議保證
- 因果有序由follower的歷史隊列(history queue)保證
ZAB工作模式
ZAB 協議是爲分佈式協調服務 ZooKeeper 專門設計的一種支持崩潰恢復的原子廣播協議。在 ZooKeeper 中，主要依賴 ZAB 協議來實現分佈式數據一致性。ZAB協議兩種模式：消息廣播和崩潰恢復`。
廣播(broadcast)模式
- leader從客戶端收到一個寫請求
- leader生成一個新的事務併爲這個事務生成一個唯一的ZXID，
- leader將這個事務發送給所有的follows節點，將帶有 zxid 的消息作爲一個提案(proposal)分發給所有 follower。
- follower節點將收到的事務請求加入到歷史隊列(history queue)中，當 follower 接收到 proposal，先將 proposal 寫到硬盤，寫硬盤成功後再向 leader 回一個 ACK。
- 當leader收到大多數follower（超過法定數量）的ack消息，leader會發送commit請求
- 當follower收到commit請求時，會判斷該事務的ZXID是不是比歷史隊列中的任何事務的ZXID都小，如果是則提交，如果不是則等待比它更小的事務的commit(保證順序性)
![在這裏插入圖片描述]()
恢復(recovery)模式
恢復模式大致可以分爲四個階段 選舉、發現、同步、廣播。
- 當leader崩潰後，集羣進入選舉階段，開始選舉出潛在的新leader(一般爲集羣中擁有最大
ZXID的節點) - 進入發現階段，follower與潛在的新leader進行溝通，如果發現超過法定人數的follower同意，則潛在的新leader將epoch加1，進入新的紀元。新的leader產生
- 集羣間進行數據同步，保證集羣中各個節點的事務一致
- 集羣恢復到廣播模式，開始接受客戶端的寫請求
當 leader在
commit之後但在發出commit消息之前宕機，即只有老leader自己commit了，而其它follower都沒有收到commit消息 新的leader也必須保證這個proposal被提交.(新的leader會重新發送該proprosal的commit消息)
當 leader產生某個
proprosal之後但在發出消息之前宕機，即只有老leader自己有這個proproal，當老的leader重啓後(此時左右follower),新的leader必須保證老的leader必須丟棄這個proprosal.(新的leader會通知上線後的老leader截斷其epoch對應的最後一個commit的位置)
- 每個Server會發出一個投票,第一次都是投自己。投票信息：（myid，ZXID）
- 收集來自各個服務器的投票
- 處理投票並重新投票，處理邏輯：優先比較ZXID,然後比較myid
- 統計投票，只要超過半數的機器接收到同樣的投票信息，就可以確定leader
- 改變服務器狀態
腦裂
ZAB爲解決腦裂問題，要求集羣內的節點數量爲2N+1, 當網絡分裂後，始終有一個集羣的節點數量過半數，而另一個節點數量小於N+1, 因爲選主需要過半數節點同意，所以任何情況下集羣中都不可能出現大於一個leader的情況。