1、前言

隨著PC機性能的不斷提升和網(wǎng)絡(luò)技術(shù)的快速普及冀惭，很多企業(yè)開始放棄原來的大型主機染坯，而改用小型機和普通PC服務(wù)器來搭建分布式的計算機系統(tǒng)。其中最為典型的就是阿里巴巴集團的 "去 IOE" 運動倚评。

在以前集中式的應(yīng)用浦徊，我們很容易的能夠?qū)崿F(xiàn)一套滿足ACID特性的事務(wù)處理系統(tǒng)，來保證數(shù)據(jù)的嚴格一致性天梧。但在分布式的應(yīng)用中盔性，數(shù)據(jù)分散在各臺不同的機器上，要想保證數(shù)據(jù)的嚴格一致性就很難了呢岗。因此出現(xiàn)了CAP和BASE這樣的分布式系統(tǒng)經(jīng)典理論冕香。

1.1、ACID

事務(wù)（Transaction）是由一系列對系統(tǒng)中數(shù)據(jù)進行訪問與更新的操作所組成的一個程序執(zhí)行邏輯單元（Unit）,狹義上的事務(wù)特指數(shù)據(jù)庫事務(wù)后豫。

事務(wù)包含四大特性悉尾，分別是原子性（Atomicity）、一致性（Consistency）挫酿、隔離性（Isolation）和持久性（Durability）构眯。

1.1.1、原子性

原子性是指事務(wù)必須是一個原子的操作序列單元早龟。每一個事務(wù)的所有操作要么全部成功惫霸，要么全部失敗。

1.1.2葱弟、一致性

一致性是指事務(wù)的執(zhí)行不能破環(huán)數(shù)據(jù)庫數(shù)據(jù)的完整性和一致性壹店。一個事務(wù)在執(zhí)行之前和執(zhí)行之后，數(shù)據(jù)庫都必須處于一致性狀態(tài)芝加。

1.1.3硅卢、隔離性

隔離性是指并發(fā)的事務(wù)是相互隔離的，一個事務(wù)的執(zhí)行不能被其他事務(wù)干擾。

1.1.4老赤、持久性

持久性是指一個事務(wù)一旦提交轮洋，它對數(shù)據(jù)庫中對應(yīng)數(shù)據(jù)的狀態(tài)變更就應(yīng)該是永久性的。

1.2抬旺、CAP定理

CAP定理是指一個分布式系統(tǒng)不可能同時滿足一致性（C：Consistency）弊予、可用性（A：Availability）和分區(qū)容錯性（P：Partition tolerance）這三個基本需求，最多只能同時滿足其中的兩項开财。因為分布式系統(tǒng)中分區(qū)容錯性是一定存在的汉柒，所以主要還是在一致性和可用性中進行權(quán)衡選擇。

cap.jpg

1.2.1责鳍、一致性

在分布式環(huán)境中碾褂，一致性是指數(shù)據(jù)在多個副本之間是否能夠保持一致的特性。在一致性的需求下历葛，當一個系統(tǒng)在數(shù)據(jù)一致的狀態(tài)下執(zhí)行更新操作后正塌，應(yīng)該保證系統(tǒng)的數(shù)據(jù)仍然處于一致的狀態(tài)。

對于一個將數(shù)據(jù)副本分布在不同分布式節(jié)點上的系統(tǒng)來說恤溶，如果對第一個節(jié)點的數(shù)據(jù)進行了更新操作并且更新成功后乓诽，卻沒有使得第二個節(jié)點上的數(shù)據(jù)得到相應(yīng)的更新，于是在對第二個節(jié)點的數(shù)據(jù)進行讀取操作時咒程，獲取的依然是老數(shù)據(jù)（或稱為臟數(shù)據(jù)）鸠天，這就是典型的分布式數(shù)據(jù)不一致情況。在分布式系統(tǒng)中帐姻，如果能夠做到針對一個數(shù)據(jù)項的更新操作執(zhí)行成功后稠集，所有的用戶都可以讀取到其最新的值，那么這樣的系統(tǒng)就被認為具有強一致性（或嚴格的一致性）饥瓷。

1.2.2剥纷、可用性

可用性是指系統(tǒng)提供的服務(wù)必須一直處于可用的狀態(tài)，對于用戶的每一個操作請求總是能夠在有限的時間內(nèi)返回結(jié)果扛伍。

1.2.3筷畦、分區(qū)容錯性

分區(qū)容錯性約束了一個分布式系統(tǒng)需要具有如下特性：分布式系統(tǒng)在遇到任何網(wǎng)絡(luò)分區(qū)故障的時候，仍然需要能夠保證對外提供滿足一致性和可用性的服務(wù)刺洒，除非是整個網(wǎng)絡(luò)環(huán)境都發(fā)生了故障鳖宾。

網(wǎng)絡(luò)分區(qū)是指在分布式系統(tǒng)中，不同的節(jié)點分布在不同的子網(wǎng)絡(luò)（機房或異地網(wǎng)絡(luò)等）中逆航，由于一些特殊的原因?qū)е逻@些子網(wǎng)絡(luò)之間出現(xiàn)網(wǎng)絡(luò)不連通的狀況鼎文，但各個子網(wǎng)絡(luò)的內(nèi)部網(wǎng)絡(luò)是正常的，從而導(dǎo)致整個系統(tǒng)的網(wǎng)絡(luò)環(huán)境被切分成了若干個孤立的區(qū)域因俐。需要注意的是拇惋，組成一個分布式系統(tǒng)的每個節(jié)點的加入與退出都可以看作是一個特殊的網(wǎng)絡(luò)分區(qū)周偎。

1.3、BASE理論

BASE理論是指 Basically Available（基本可用）撑帖、Soft state（軟狀態(tài)）和 Eventually consistent（最終一致性）三個短語的簡寫蓉坎。是對 CAP 中一致性和可用性權(quán)衡的結(jié)果。是基于 CAP 定理逐步演化而來的胡嘿，其核心思想是即使無法做到強一致性蛉艾，但每個應(yīng)用都可以根據(jù)自身的業(yè)務(wù)特點，采用適當?shù)姆绞絹硎瓜到y(tǒng)達到最終一致性衷敌。

1.3.1勿侯、基本可用

基本可用是指分布式系統(tǒng)在出現(xiàn)不可預(yù)知故障的時候，允許損失部分可用性——但請注意缴罗，這絕不等價于系統(tǒng)不可用助琐。

1.3.2、弱狀態(tài)

弱狀態(tài)也稱為軟狀態(tài)面氓，和硬狀態(tài)相對兵钮，是指允許系統(tǒng)中的數(shù)據(jù)存在中間狀態(tài)，并認為該中間狀態(tài)的存在不會影響系統(tǒng)的整體可用性侧但，即允許系統(tǒng)在不同節(jié)點的數(shù)據(jù)副本之間進行數(shù)據(jù)同步的過程存在延時矢空。

1.3.3、最終一致性

最終一致性強調(diào)的是系統(tǒng)中所有的數(shù)據(jù)副本禀横，在經(jīng)過一段時間的同步后，最終能夠達到一個一致的狀態(tài)粥血。因此柏锄，最終一致性的本質(zhì)是需要系統(tǒng)保證最終數(shù)據(jù)能夠達到一致，而不需要實時保證系統(tǒng)數(shù)據(jù)的強一致性复亏。

2趾娃、一致性協(xié)議和算法

為了解決分布式一致性問題，在長期的探索研究過程中缔御，涌現(xiàn)出了一大批經(jīng)典的一致性協(xié)議和算法抬闷，其中最著名的就是二階段提交協(xié)議、三階段提交協(xié)議和Paxos算法耕突。

2.1笤成、2PC協(xié)議

2PC，是 Two-Phase Commit 的縮寫眷茁，即二階段提交炕泳，是計算機網(wǎng)絡(luò)尤其是在數(shù)據(jù)庫領(lǐng)域內(nèi)，為了使基于分布式系統(tǒng)架構(gòu)下的所有節(jié)點在進行事務(wù)處理過程中能夠保持原子性和一致性而設(shè)計的一種算法上祈。

2.1.1培遵、協(xié)議說明

二階段提交協(xié)議是將事務(wù)的提交過程分成了兩個階段來進行處理浙芙。在講述流程之前先介紹兩個概念：

• 協(xié)調(diào)者： 用來統(tǒng)一調(diào)度所有分布式節(jié)點的執(zhí)行邏輯。

• 參與者： 被調(diào)度的分布式節(jié)點籽腕。

其執(zhí)行流程如下：

• 階段一：提交事務(wù)請求（投票階段）

  1. 分發(fā)事務(wù)

     協(xié)調(diào)者向所有的參與者發(fā)送事務(wù)內(nèi)容嗡呼，詢問是否可以執(zhí)行事務(wù)提交操作，并開始等待各參與者的響應(yīng)皇耗。

  2. 執(zhí)行事務(wù)

     各參與者節(jié)點執(zhí)行事務(wù)操作晤锥，并將Undo 和 Redo 信息記入事務(wù)日志中。

  3. 反饋響應(yīng)

     如果參與者成功執(zhí)行了事務(wù)操作廊宪，那么就反饋給協(xié)調(diào)者 Yes 響應(yīng)矾瘾，表示事務(wù)可以執(zhí)行；

     如果參與者沒有成功執(zhí)行事務(wù)箭启，那么就反饋給協(xié)調(diào)者 No 響應(yīng)壕翩，表示事務(wù)不可以執(zhí)行。

• 階段二：執(zhí)行事務(wù)請求（執(zhí)行階段）

  協(xié)調(diào)者根據(jù)各參與者的反饋情況來決定最終是否可以進行事務(wù)提交操作傅寡，正常情況下放妈，包含以下兩種可能。

  提交事務(wù)

  ? 假如協(xié)調(diào)者從所有的參與者獲得的反饋都是 Yes 響應(yīng)荐操，那么就會執(zhí)行事務(wù)提交芜抒。

  1. 發(fā)送提交請求

     協(xié)調(diào)者向所有參與者節(jié)點發(fā)出 Commit 請求。

  2. 事務(wù)提交

     參與者接收到 Commit 請求后托启，會正式執(zhí)行事務(wù)提交操作宅倒，并在完成提交之后釋放在整個事務(wù)執(zhí)行期間占用的事務(wù)資源。

  3. 反饋事務(wù)提交結(jié)果

     參與者在完成事務(wù)提交之后屯耸，向協(xié)調(diào)者發(fā)送Ack消息拐迁。

  4. 完成事務(wù)

     協(xié)調(diào)者接收到所有參與者反饋的 Ack 消息后，完成事務(wù)疗绣。

  中斷事務(wù)

  ? 假如任何一個參與者向協(xié)調(diào)者反饋了 No 響應(yīng)线召，或者在等待超時之后，協(xié)調(diào)者尚無法接收到所有參與者的反饋響應(yīng)多矮，那么就會中斷事務(wù)缓淹。

  1. 發(fā)送回滾請求

     協(xié)調(diào)者向所有參與者節(jié)點發(fā)出 Rollback 請求。

  2. 事務(wù)回滾

     參與者接收到 Rollback 請求后塔逃，會利用其在階段一中記錄的 Undo 信息來執(zhí)行事務(wù)回滾操作讯壶，并在完成回滾之后釋放在整個事務(wù)執(zhí)行期間占用的資源。

  3. 反饋事務(wù)回滾結(jié)果

     參與者在完成事務(wù)回滾之后患雏，向協(xié)調(diào)者發(fā)送 Ack 消息鹏溯。

  4. 中斷事務(wù)

     協(xié)調(diào)者接收到所有參與者反饋的 Ack 消息后，完成事務(wù)中斷淹仑。

2.1.2丙挽、優(yōu)缺點

優(yōu)點：

• 原理簡單
• 實現(xiàn)方便

缺點：

• 同步阻塞

  二階段提交協(xié)議存在的最明顯也是最大的一個問題就是同步阻塞肺孵，這會極大地限制分布式系統(tǒng)的性能。在二階段提交的執(zhí)行過程中颜阐，所有參與該事務(wù)操作的邏輯都處于阻塞狀態(tài)平窘，也就是說，各個參與者在等待其他參與者響應(yīng)的過程中凳怨，將無法進行其他任何操作瑰艘。

• 單點問題

  在二階段提交中，一旦協(xié)調(diào)者出現(xiàn)問題肤舞，那么整個二階段提交流程將無法運轉(zhuǎn)紫新，更為嚴重的是，如果協(xié)調(diào)者是在階段二中出現(xiàn)問題的話李剖，那么其他參與者將會一直處于鎖定事務(wù)資源的狀態(tài)中芒率，而無法繼續(xù)完成事務(wù)操作。

• 數(shù)據(jù)不一致

  在二階段提交協(xié)議的階段二篙顺，即執(zhí)行事務(wù)提交的時候偶芍，當協(xié)調(diào)者向所有的參與者發(fā)送Commit 請求之后，發(fā)生了局部網(wǎng)絡(luò)異车旅担或者是協(xié)調(diào)者在尚未發(fā)送完 Commit 請求之前自身發(fā)生了崩潰匪蟀，導(dǎo)致最終只有部分參與者收到了 Commit 請求。于是宰僧，這部分收到了 Commit 請求的參與者就會進行事務(wù)的提交材彪，而其他沒有收到 Commit 請求的參與者則無法進行事務(wù)提交，于是整個分布式系統(tǒng)便出現(xiàn)了數(shù)據(jù)不一致性現(xiàn)象撒桨。

• 太過保守

  二階段提交協(xié)議沒有設(shè)計較為完善的容錯機制查刻，任意一個節(jié)點的失敗都會導(dǎo)致整個事務(wù)的失敗。

2.2凤类、3PC協(xié)議

2.2.1、協(xié)議說明

3PC普气，是 Three-Phase Commit 的縮寫谜疤，即三階段提交，是 2PC 的改進版现诀，其將二階段提交協(xié)議的“提交事務(wù)請求”過程一分為二夷磕，形成了由 CanCommit、PreCommit 和 DoCommit 三個階段組成的事務(wù)處理協(xié)議仔沿。其執(zhí)行流程如下：

• 階段一：CanCommit

  1. 事務(wù)詢問

     協(xié)調(diào)者向所有的參與者發(fā)送一個包含事務(wù)內(nèi)容的 CanCommit 請求坐桩，詢問是否可以執(zhí)行事務(wù)提交操作，并開始等待各參與者的響應(yīng)封锉。

  2. 反饋響應(yīng)

     參與者在接收到來自協(xié)調(diào)者的 CanCommit 請求后绵跷，正常情況下膘螟，如果其自身認為可以順利執(zhí)行事務(wù)，那么會反饋 Yes 響應(yīng)碾局，并進入預(yù)備狀態(tài)荆残，否則反饋 No 響應(yīng)。

• 階段二：PreCommit

  協(xié)調(diào)者會根據(jù)各參與者的反饋情況來決定是否可以進行事務(wù)的 PreCommit 操作净当，正常情況下内斯，包含兩種可能。

  執(zhí)行事務(wù)預(yù)提交

  ? 假如協(xié)調(diào)者從所有的參與者獲得的反饋都是 Yes 響應(yīng)像啼，那么就會執(zhí)行事務(wù)預(yù)提交俘闯。

  1. 發(fā)送預(yù)提交請求

     協(xié)調(diào)者向所有參與者節(jié)點發(fā)出 PreCommit 的請求，并進入 Prepared 階段忽冻。

  2. 事務(wù)預(yù)提交

     參與者接收到 PreCommit 請求后真朗，會執(zhí)行事務(wù)操作，并將 Undo 和 Redo 信息記錄到事務(wù)日志中甚颂。

  3. 反饋響應(yīng)

     如果參與者成功執(zhí)行了事務(wù)操作蜜猾，那么就會反饋給協(xié)調(diào)者 Ack 響應(yīng)，同時等待最終的指令：提交 （commit）或中止（abort）振诬。

  中斷事務(wù)

  ? 假如任何一個參與者向協(xié)調(diào)者反饋了No 響應(yīng)蹭睡，或者在等待超時之后，協(xié)調(diào)者尚無法接收到所有參與者的反饋響應(yīng)赶么，那么就會中斷事務(wù)肩豁。

  1. 發(fā)送中斷請求

     協(xié)調(diào)者向所有參與者節(jié)點發(fā)出 abort 請求。

  2. 中斷事務(wù)

     無論是收到來自協(xié)調(diào)者的 abort 請求辫呻，或者是在等待協(xié)調(diào)者請求過程中出現(xiàn)超時清钥，參與者都會中斷事務(wù)。

• 階段三：DoCommit

  該階段將進行真正的事務(wù)提交放闺，會存在以下兩種可能的情況祟昭。

  執(zhí)行提交

  1. 發(fā)送提交請求

     進入這一階段，假設(shè)協(xié)調(diào)者處于正常工作狀態(tài)怖侦，并且它接收到了來自所有參與者的 Ack 響應(yīng)篡悟，那么它將從 “預(yù)提交” 狀態(tài)轉(zhuǎn)換到 “提交” 狀態(tài)，并向所有的參與者發(fā)送 doCommit 請求匾寝。

  2. 事務(wù)提交

     參與者接收到 doCommit 請求后搬葬，會正式執(zhí)行事務(wù)提交操作，并在完成提交之后釋放在整個事務(wù)執(zhí)行期間占用的事務(wù)資源艳悔。

  3. 反饋事務(wù)提交結(jié)果

     參與者在完成事務(wù)提交之后急凰，向協(xié)調(diào)者發(fā)送 Ack 消息。

  4. 完成事務(wù)

     協(xié)調(diào)者接收到所有參與者反饋的 Ack 消息后猜年，完成事務(wù)抡锈。

  中斷事務(wù)

  ? 進入這一階段疾忍，假設(shè)協(xié)調(diào)者處于正常工作狀態(tài)，并且有任意一個參與者向協(xié)調(diào)者反饋了No 響應(yīng)企孩，或者在等待超時之后锭碳，協(xié)調(diào)者尚無法接收到所有參與者的反饋響應(yīng)，那么就會中斷事務(wù)勿璃。

  1. 發(fā)送中斷請求

     協(xié)調(diào)者向所有的參與者節(jié)點發(fā)送 abort 請求擒抛。

  2. 事務(wù)回滾

     參與者接收到 abort 請求后，會利用其在階段二中記錄的 Undo 信息來執(zhí)行事務(wù)回滾操作补疑，并在完成回滾之后釋放在整個事務(wù)執(zhí)行期間占用的資源歧沪。

  3. 反饋事務(wù)回滾結(jié)果

     參與者在完成事務(wù)回滾之后，向協(xié)調(diào)者發(fā)送 Ack 消息莲组。

  4. 中斷事務(wù)

     協(xié)調(diào)者接收到所有參與者反饋的 Ack 消息后诊胞，中斷事務(wù)。

  注意：階段三可能會存在以下兩種故障

  • 協(xié)調(diào)者出現(xiàn)問題锹杈。
  • 協(xié)調(diào)者和參與者之間的網(wǎng)絡(luò)出現(xiàn)故障撵孤。

  無論出現(xiàn)哪種情況，最終都會導(dǎo)致參與者無法及時接收到來自協(xié)調(diào)者的 doCommit 或是 abort 請求竭望，針對這樣的異常情況邪码，參與者都會在等待超時之后，繼續(xù)進行事務(wù)提交咬清。

2.2.2闭专、優(yōu)缺點

優(yōu)點：

• 相較于二階段提交，三階段提交降低了參與者的阻塞范圍旧烧。
• 能夠在出現(xiàn)單點故障后繼續(xù)達成一致影钉。

缺點：

• 數(shù)據(jù)不一致

  在參與者接收到 preCommit 消息后，如果網(wǎng)絡(luò)出現(xiàn)分區(qū)掘剪，此時協(xié)調(diào)者所在的節(jié)點和參與者無法進行正常的網(wǎng)絡(luò)通信平委，在這種情況下，該參與者依然會進行事務(wù)的提交夺谁，這必然出現(xiàn)數(shù)據(jù)的不一致性肆汹。

2.3、Paxos算法

Paxos 算法是一種基于消息傳遞且具有高度容錯特性的一致性算法予权。是目前公認的解決分布式一致性問題最有效的算法之一。（這里不介紹Paxos算法浪册，后面會寫一篇文章專題講講Paxos算法）

3扫腺、ZAB（Zookeeper Atomic Broadcast）協(xié)議

ZAB協(xié)議是為分布式協(xié)調(diào)服務(wù)Zookeeper專門設(shè)計的一種支持崩潰恢復(fù)的原子廣播協(xié)議〈逑螅基于該協(xié)議笆环，Zookeeper實現(xiàn)了一種主備模式的系統(tǒng)架構(gòu)來保持集群中各副本之間數(shù)據(jù)的一致性攒至。

3.1、核心處理過程

所有事務(wù)請求必須由一個全局唯一的服務(wù)器來協(xié)調(diào)處理躁劣，這樣的服務(wù)器被稱為 Leader 服務(wù)器迫吐，而余下的其他服務(wù)器則成為 Follower 服務(wù)器。 Leader 服務(wù)器負責(zé)將一個客戶端事務(wù)請求轉(zhuǎn)換成一個事務(wù) Proposal（提議）账忘，并將該 Proposal 分發(fā)給集群中所有的 Follower 服務(wù)器志膀。之后 Leader 服務(wù)器需要等待所有 Follower 服務(wù)器的反饋，一旦超過半數(shù)的 Follower 服務(wù)器進行了正確的反饋后鳖擒，那么 Leader 就會再次向所有的 Follower 服務(wù)器分發(fā) Commit 消息溉浙，要求其將前一個 Proposal 進行提交。

3.2蒋荚、協(xié)議介紹

ZAB協(xié)議包括兩種基本的模式戳稽，分別是崩潰恢復(fù)和消息廣播。當整個服務(wù)框架在啟動過程中期升，或是當 Leader 服務(wù)器出現(xiàn)網(wǎng)絡(luò)中斷惊奇，崩潰退出與重啟等異常情況時，ZAB 協(xié)議就會進入恢復(fù)模式并選舉產(chǎn)生新的 Leader 服務(wù)器播赁。當選舉產(chǎn)生了新的 Leader 服務(wù)器颂郎，同時集群中已經(jīng)有過半的機器與該 Leader 服務(wù)器完成了狀態(tài)同步（數(shù)據(jù)同步）之后，ZAB 協(xié)議就會退出恢復(fù)模式行拢，進入消息廣播模式祖秒。Leader 服務(wù)器在接收到客戶端的事務(wù)請求后，會生成對應(yīng)的事務(wù)提案并發(fā)起一輪廣播協(xié)議舟奠；而如果集群中的其他機器接收到客戶端的寫事務(wù)請求竭缝，那么這些非 Leader 服務(wù)器會首先將這個事務(wù)請求轉(zhuǎn)發(fā)給 Leader 服務(wù)器。
如果新加入了一臺服務(wù)器沼瘫，此服務(wù)器就會進入數(shù)據(jù)恢復(fù)模式抬纸，找到Leader 所在的服務(wù)器，并與其進行數(shù)據(jù)同步耿戚，然后一起參與到消息廣播流程中去湿故。

3.2.1、崩潰恢復(fù)模式

當整個服務(wù)器框架啟動過程中膜蛔，或是當 Leader 服務(wù)器出現(xiàn)崩潰坛猪，或者說由于網(wǎng)絡(luò)原因?qū)е?Leader 服務(wù)器失去了與過半 Follower 的聯(lián)系，那么就會進入崩潰恢復(fù)模式皂股。（說白了崩潰恢復(fù)模式就是選舉新的 Leader墅茉，完成數(shù)據(jù)同步）

在崩潰恢復(fù)過程中可能會出現(xiàn)兩個數(shù)據(jù)不一致性的問題：

• ZAB 協(xié)議需要確保那些已經(jīng)在 Leader服務(wù)器上提交的事務(wù)最終被所有服務(wù)器都提交。

  假設(shè)一個事務(wù)在 Leader 服務(wù)器上被提交了，并且已經(jīng)得到過半的 Follower 服務(wù)器的 Ack 反饋就斤，但是在它將 Commit 消息發(fā)送給所有 Follower 機器之前悍募，Leader 服務(wù)器掛了。針對這種情況洋机， ZAB 協(xié)議就需要確保事務(wù)最終能夠在所有的服務(wù)器上都被提交成功坠宴，否則將出現(xiàn)不一致。

• ZAB 協(xié)議需要確保丟棄那些只在 Leader 服務(wù)器上被提出的事務(wù)绷旗。

  假設(shè)在 Leader 服務(wù)器上 Server1 提出了一個事務(wù)之后就崩潰退出了喜鼓，從而導(dǎo)致集群中的其他服務(wù)器都沒有收到這個事務(wù)。于是刁标，當 Server1 恢復(fù)過來再次加入到集群中的時候颠通，ZAB 協(xié)議需要確保丟棄這個事務(wù)。

對于上面提出的問題膀懈，決定了 ZAB 協(xié)議必須設(shè)計這樣一個 Leader 選舉算法：能夠確保提交已經(jīng)被 Leader 提交的事務(wù) Proposal顿锰，同時丟棄已經(jīng)被跳過的事務(wù) Proposal。針對這個要求启搂，如果讓 Leader 選舉算法能夠保證新選舉出來的 Leader 服務(wù)器擁有集群中所有機器最高編號（即 ZXID 最大）的事務(wù) Proposal硼控，那么就可以保證這個新選舉出來的 Leader 一定具有所有已經(jīng)提交的提案。更為重要的是如果讓具有最高編號事務(wù) Proposal 的機器來成為 Leader 胳赌，就可以省去 Leader 服務(wù)器檢查 Proposal 的提交和丟棄工作的這一步操作了牢撼。（Leader選舉過程請看 《Zookeeper深入原理》）

在完成 Leader 選舉之后，正式開始工作之前疑苫，還需要確認事務(wù)日志中的所有 Proposal 是否都已經(jīng)被集群中過半的機器提交了熏版，即是否完成了數(shù)據(jù)同步。

下面介紹一下數(shù)據(jù)同步過程：

Leader服務(wù)器會為每一個 Follower服務(wù)器都準備一個隊列捍掺，并將那些沒有被各 Follower 服務(wù)器同步的事務(wù)以 Proposal 消息的形式逐個發(fā)送給 Follower 服務(wù)器撼短，并在每一個 Proposal 消息后面緊接著再發(fā)送一個 Commit 消息，以表示該事務(wù)已經(jīng)被提交挺勿。等到 Follower 服務(wù)器將所有其尚未同步的事務(wù) Proposal 都從 Leader 服務(wù)器上同步過來并成功應(yīng)用到本地數(shù)據(jù)庫中后曲横，Leader 服務(wù)器就會將該 Follower 服務(wù)器加入到真正的可用 Follower 列表中。

3.2.2不瓶、消息廣播模式

ZAB 協(xié)議的消息廣播過程使用的是一個原子廣播協(xié)議禾嫉，類似于一個二階段提交的過程。但是 ZAB 協(xié)議與二階段提交略有不同蚊丐。在 ZAB 協(xié)議的二階段提交過程中熙参，移除了中斷邏輯，所有的 Follower 服務(wù)器要么正常反饋 Leader 提出的事務(wù) Proposal麦备，要么就拋棄 Leader 服務(wù)器尊惰。同時 ZAB 協(xié)議支持半數(shù)原則讲竿，即超過半數(shù)的 Follower 服務(wù)器反饋 Ack 之后就開始提交事務(wù) Proposal 了，而不需要等待集群中所有的 Follower 服務(wù)器都反饋響應(yīng)弄屡。

因為這種簡化的二階段提交模型下，是無法處理 Leader 服務(wù)器崩潰退出而帶來的數(shù)據(jù)不一致問題的鞋诗，因此在ZAB 協(xié)議中添加了崩潰恢復(fù)模式來解決這種問題膀捷。

在消息廣播過程中，Leader 服務(wù)器會為每一個事務(wù)請求生成對應(yīng)的 Proposal 來進行廣播削彬，并且在廣播事務(wù) Proposal 之前全庸，Leader 服務(wù)器會首先為這個事務(wù) Proposal 分配一個全局單調(diào)遞增的唯一ID（即 ZXID），Leader服務(wù)器會為每一個 Follower 服務(wù)器都各自分配一個單獨的隊列融痛，然后將需要廣播的事務(wù) Proposal 依次放入這些隊列中去壶笼，并且根據(jù) FIFO 策略進行消息發(fā)送。每一個 Follower 服務(wù)器在接收到這個事務(wù) Proposal 之后雁刷，都會首先將其以事務(wù)日志的形式寫入到本地磁盤中去覆劈，并且在成功寫入后反饋給 Leader 服務(wù)器一個 Ack 響應(yīng)拓春。當 Leader 服務(wù)器接收到超過半數(shù) Follower 的 Ack 響應(yīng)后楷力，就會廣播一個 Commit 消息給所有的 Follower 服務(wù)器以通知其進行事務(wù)提交，同時 Leader 自身也會完成對事務(wù)的提交椿每，而每一個 Follower 服務(wù)器在接收到 Commit 消息后目派，也會完成對事務(wù)的提交坤候。

3.3、協(xié)議說明

整個 ZAB 協(xié)議主要包括消息廣播和崩潰恢復(fù)兩個過程企蹭，進一步可以細分為三個階段白筹，分別是發(fā)現(xiàn)（Discovery）、同步（Synchronization）和廣播（Broadcast）階段谅摄。

階段一：發(fā)現(xiàn)

主要就是 Leader 選舉過程徒河，用于在多個分布式進程中選舉出主進程。

階段二：同步

在完成發(fā)現(xiàn)流程之后螟凭，就進入了同步階段虚青。即 Leader 服務(wù)器和 Follower 服務(wù)器之間同步數(shù)據(jù)。

階段三：廣播

完成同步階段之后螺男，ZAB 協(xié)議就可以正式開始接收客戶端新的事物請求棒厘，并進行消息廣播流程。