設(shè)計(jì)一個(gè)分布式系統(tǒng)必定會遇到一個(gè)問題—— 因?yàn)榉謪^(qū)容忍性（partition tolerance）的存在，就必定要求我們需要在系統(tǒng)可用性（availability）和數(shù)據(jù)一致性（consistency）中做出權(quán)衡 。這就是著名的 CAP

一致性模型

一致性（Consistency）是指多副本（Replications）問題中的數(shù)據(jù)一致性。關(guān)于分布式系統(tǒng)的一致性模型有以下幾種：

• 強(qiáng)一致性：當(dāng)更新操作完成之后，任何多個(gè)后續(xù)進(jìn)程或者線程的訪問都會返回最新的更新過的值，直到這個(gè)數(shù)據(jù)被其他數(shù)據(jù)更新為止。但是這種實(shí)現(xiàn)對性能影響較大，因?yàn)檫@意味著，只要上次的操作沒有處理完，就不能讓用戶讀取數(shù)據(jù)。
• 弱一致性：系統(tǒng)并不保證進(jìn)程或者線程的訪問都會返回最新更新過的值。系統(tǒng)在數(shù)據(jù)寫入成功之后，不承諾立即可以讀到最新寫入的值，也不會具體的承諾多久之后可以讀到。甚至不能保證可以訪問到。
• 最終一致性：最終一致性也是弱一致性的一種，它無法保證數(shù)據(jù)更新后，所有后續(xù)的訪問都能看到最新數(shù)值，而是需要一個(gè)時(shí)間，在這個(gè)時(shí)間之后可以保證這一點(diǎn)（就是在一段時(shí)間后，節(jié)點(diǎn)間的數(shù)據(jù)會最終達(dá)到一致狀態(tài)），而在這個(gè)時(shí)間內(nèi)，數(shù)據(jù)也許是不一致的，這個(gè)系統(tǒng)無法保證強(qiáng)一致性的時(shí)間片段被稱為「不一致窗口」。不一致窗口的時(shí)間長短取決于很多因素，比如備份數(shù)據(jù)的個(gè)數(shù)、網(wǎng)絡(luò)傳輸延遲速度、系統(tǒng)負(fù)載等。

一致性協(xié)議

為了解決分布式系統(tǒng)的一致性問題，在長期的研究探索過程中，業(yè)內(nèi)涌現(xiàn)出了一大批經(jīng)典的一致性協(xié)議和算法，其中比較著名的有二階段提交協(xié)議（2PC），三階段提交協(xié)議（3PC）和 Paxos 算法。

分布式事務(wù)

分布式事務(wù)是指會涉及到操作多個(gè)數(shù)據(jù)庫的事務(wù)。其實(shí)就是將對同一庫事務(wù)的概念擴(kuò)大到了對多個(gè)庫的事務(wù)。

目的是為了保證分布式系統(tǒng)中的數(shù)據(jù)一致性。

分布式事務(wù)處理的關(guān)鍵是必須有一種方法可以知道事務(wù)在任何地方所做的所有動(dòng)作，提交或回滾事務(wù)的決定必須產(chǎn)生統(tǒng)一的結(jié)果（全部提交或全部回滾）

在分布式系統(tǒng)中，各個(gè)節(jié)點(diǎn)之間在物理上相互獨(dú)立，通過網(wǎng)絡(luò)進(jìn)行溝通和協(xié)調(diào)。由于存在事務(wù)機(jī)制，可以保證每個(gè)獨(dú)立節(jié)點(diǎn)上的數(shù)據(jù)操作可以滿足ACID。但是，相互獨(dú)立的節(jié)點(diǎn)之間無法準(zhǔn)確的知道其他節(jié)點(diǎn)中的事務(wù)執(zhí)行情況。所以從理論上講，兩臺機(jī)器理論上無法達(dá)到一致的狀態(tài)。如果想讓分布式部署的多臺機(jī)器中的數(shù)據(jù)保持一致性，那么就要保證在所有節(jié)點(diǎn)的數(shù)據(jù)寫操作，要不全部都執(zhí)行，要么全部的都不執(zhí)行。但是，一臺機(jī)器在執(zhí)行本地事務(wù)的時(shí)候無法知道其他機(jī)器中的本地事務(wù)的執(zhí)行結(jié)果。所以他也就不知道本次事務(wù)到底應(yīng)該commit還是 roolback。所以，常規(guī)的解決辦法就是引入一個(gè)“協(xié)調(diào)者”的組件來統(tǒng)一調(diào)度所有分布式節(jié)點(diǎn)的執(zhí)行。

XA規(guī)范

X/Open 組織（即現(xiàn)在的 Open Group ）定義了分布式事務(wù)處理模型。

X/Open DTP 模型（ 1994 ）包括應(yīng)用程序（ AP ）、事務(wù)管理器（ TM ）、資源管理器（ RM ）、通信資源管理器（ CRM ）四部分。一般，常見的事務(wù)管理器（ TM ）是交易中間件，常見的資源管理器（ RM ）是數(shù)據(jù)庫，常見的通信資源管理器（ CRM ）是消息中間件。

通常把一個(gè)數(shù)據(jù)庫內(nèi)部的事務(wù)處理，如對多個(gè)表的操作，作為本地事務(wù)看待。數(shù)據(jù)庫的事務(wù)處理對象是本地事務(wù)，而分布式事務(wù)處理的對象是全局事務(wù)。所謂全局事務(wù)，是指分布式事務(wù)處理環(huán)境中，多個(gè)數(shù)據(jù)庫可能需要共同完成一個(gè)工作，這個(gè)工作即是一個(gè)全局事務(wù)，例如，一個(gè)事務(wù)中可能更新幾個(gè)不同的數(shù)據(jù)庫。對數(shù)據(jù)庫的操作發(fā)生在系統(tǒng)的各處但必須全部被提交或回滾。此時(shí)一個(gè)數(shù)據(jù)庫對自己內(nèi)部所做操作的提交不僅依賴本身操作是否成功，還要依賴與全局事務(wù)相關(guān)的其它數(shù)據(jù)庫的操作是否成功，如果任一數(shù)據(jù)庫的任一操作失敗，則參與此事務(wù)的所有數(shù)據(jù)庫所做的所有操作都必須回滾。

一般情況下，某一數(shù)據(jù)庫無法知道其它數(shù)據(jù)庫在做什么，因此，在一個(gè) DTP 環(huán)境中，交易中間件是必需的，由它通知和協(xié)調(diào)相關(guān)數(shù)據(jù)庫的提交或回滾。而一個(gè)數(shù)據(jù)庫只將其自己所做的操作（可恢復(fù)）影射到全局事務(wù)中。

XA 就是 X/Open DTP 定義的交易中間件與數(shù)據(jù)庫之間的接口規(guī)范（即接口函數(shù)），交易中間件用它來通知數(shù)據(jù)庫事務(wù)的開始、結(jié)束以及提交、回滾等。XA 接口函數(shù)由數(shù)據(jù)庫廠商提供。

二階提交協(xié)議和三階提交協(xié)議就是根據(jù)這一思想衍生出來的?？梢哉f二階段提交其實(shí)就是實(shí)現(xiàn)XA分布式事務(wù)的關(guān)鍵(確切地說：兩階段提交主要保證了分布式事務(wù)的原子性：即所有結(jié)點(diǎn)要么全做要么全不做)

2PC

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

現(xiàn)在很多數(shù)據(jù)庫都是采用的二階段提交協(xié)議來完成分布式事務(wù)的處理。

二階段，顧名思義就是分兩個(gè)階段處理事務(wù)，流程如下：

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

當(dāng)要執(zhí)行一個(gè)分布式事務(wù)的時(shí)候，事務(wù)發(fā)起者首先向協(xié)調(diào)者發(fā)起事務(wù)請求，然后協(xié)調(diào)者會給所有參與者發(fā)送 prepare 請求（其中包括事務(wù)內(nèi)容）告訴參與者你們需要執(zhí)行事務(wù)了，如果能執(zhí)行我發(fā)的事務(wù)內(nèi)容那么就先執(zhí)行但不提交，執(zhí)行后請給我回復(fù)。然后參與者收到 prepare 消息后，他們會開始執(zhí)行事務(wù)（但不提交），并將 Undo 和 Redo 信息記入事務(wù)日志中，之后參與者就向協(xié)調(diào)者反饋是否準(zhǔn)備好了

階段二：執(zhí)行事務(wù)提交

協(xié)調(diào)者根據(jù)各參與者的反饋情況決定最終是否可以提交事務(wù)，如果反饋都是Yes，發(fā)送提交commit請求，參與者提交成功后返回 Ack 消息，協(xié)調(diào)者接收后就完成了。如果反饋是No 或者超時(shí)未反饋，發(fā)送 Rollback 請求，利用階段一記錄表的 Undo 信息執(zhí)行回滾，并反饋給協(xié)調(diào)者Ack ，中斷消息

優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：原理簡單、實(shí)現(xiàn)方便。

缺點(diǎn)：

• 單點(diǎn)故障問題，如果協(xié)調(diào)者掛了那么整個(gè)系統(tǒng)都處于不可用的狀態(tài)了
• 阻塞問題，即當(dāng)協(xié)調(diào)者發(fā)送 prepare 請求，參與者收到之后如果能處理那么它將會進(jìn)行事務(wù)的處理但并不提交，這個(gè)時(shí)候會一直占用著資源不釋放，如果此時(shí)協(xié)調(diào)者掛了，那么這些資源都不會再釋放了，這會極大影響性能
• 數(shù)據(jù)不一致問題，比如當(dāng)?shù)诙A段，協(xié)調(diào)者只發(fā)送了一部分的 commit 請求就掛了，那么也就意味著，收到消息的參與者會進(jìn)行事務(wù)的提交，而后面沒收到的則不會進(jìn)行事務(wù)提交，那么這時(shí)候就會產(chǎn)生數(shù)據(jù)不一致性問題

3PC

3PC，是 Three-Phase-Comimit 的縮寫，即「三階段提交」，是二階段的改進(jìn)版，將二階段提交協(xié)議的“提交事務(wù)請求”過程一分為二。

階段一：CanCommit

協(xié)調(diào)者向所有參與者發(fā)送 CanCommit 請求，參與者收到請求后會根據(jù)自身情況查看是否能執(zhí)行事務(wù)，如果可以則返回 YES 響應(yīng)并進(jìn)入預(yù)備狀態(tài)，否則返回 NO

階段二：PreCommit

協(xié)調(diào)者根據(jù)參與者返回的響應(yīng)來決定是否可以進(jìn)行下面的 PreCommit 操作。如果上面參與者返回的都是 YES，那么協(xié)調(diào)者將向所有參與者發(fā)送 PreCommit 預(yù)提交請求，參與者收到預(yù)提交請求后，會進(jìn)行事務(wù)的執(zhí)行操作，并將 Undo 和 Redo 信息寫入事務(wù)日志中 ，最后如果參與者順利執(zhí)行了事務(wù)則給協(xié)調(diào)者返回成功的 Ack 響應(yīng)。如果在第一階段協(xié)調(diào)者收到了 任何一個(gè) NO 的信息，或者 在一定時(shí)間內(nèi) 并沒有收到全部的參與者的響應(yīng)，那么就會中斷事務(wù)，它會向所有參與者發(fā)送中斷請求 abort，參與者收到中斷請求之后會立即中斷事務(wù)，或者在一定時(shí)間內(nèi)沒有收到協(xié)調(diào)者的請求，它也會中斷事務(wù)

階段三：DoCommit

這個(gè)階段其實(shí)和 2PC 的第二階段差不多，如果協(xié)調(diào)者收到了所有參與者在 PreCommit 階段的 YES 響應(yīng)，那么協(xié)調(diào)者將會給所有參與者發(fā)送 DoCommit 請求，參與者收到 DoCommit 請求后則會進(jìn)行事務(wù)的提交工作，完成后則會給協(xié)調(diào)者返回響應(yīng)，協(xié)調(diào)者收到所有參與者返回的事務(wù)提交成功的響應(yīng)之后則完成事務(wù)。若協(xié)調(diào)者在 PreCommit 階段 收到了任何一個(gè) NO 或者在一定時(shí)間內(nèi)沒有收到所有參與者的響應(yīng) ，那么就會進(jìn)行中斷請求的發(fā)送，參與者收到中斷請求后則會 通過上面記錄的回滾日志 來進(jìn)行事務(wù)的回滾操作，并向協(xié)調(diào)者反饋回滾狀況，協(xié)調(diào)者收到參與者返回的消息后，中斷事務(wù)。

優(yōu)缺點(diǎn)

降低了參與者的阻塞范圍，且能在單點(diǎn)故障后繼續(xù)達(dá)成一致。

但是最重要的一致性并沒有得到根本的解決，比如在 PreCommit 階段，當(dāng)一個(gè)參與者收到了請求之后其他參與者和協(xié)調(diào)者掛了或者出現(xiàn)了網(wǎng)絡(luò)分區(qū)，這個(gè)時(shí)候收到消息的參與者都會進(jìn)行事務(wù)提交，這就會出現(xiàn)數(shù)據(jù)不一致性問題。

Paxos 算法

從「拜占庭將軍問題」到「Paxos小島的故事」誕生了 Paxos 算法。

Paxos 算法是基于消息傳遞且具有高度容錯(cuò)特性的一致性算法，是目前公認(rèn)的解決分布式一致性問題最有效的算法之一，其解決的問題就是在分布式系統(tǒng)中如何就某個(gè)值（決議）達(dá)成一致 。

在 Paxos 中主要有三個(gè)角色，分別為 Proposer提案者、Acceptor表決者、Learner學(xué)習(xí)者。Paxos 算法和 2PC 一樣，也有兩個(gè)階段，分別為 Prepare 和 accept 階段。

在具體的實(shí)現(xiàn)中，一個(gè)進(jìn)程可能同時(shí)充當(dāng)多種角色。比如一個(gè)進(jìn)程可能既是 Proposer 又是 Acceptor 又是Learner。Proposer 負(fù)責(zé)提出提案，Acceptor 負(fù)責(zé)對提案作出裁決（accept與否），learner 負(fù)責(zé)學(xué)習(xí)提案結(jié)果。

還有一個(gè)很重要的概念叫「提案」（Proposal）。最終要達(dá)成一致的 value 就在提案里。只要 Proposer 發(fā)的提案被半數(shù)以上的 Acceptor 接受，Proposer 就認(rèn)為該提案里的 value 被選定了。Acceptor 告訴 Learner 哪個(gè) value 被選定，Learner 就認(rèn)為那個(gè) value 被選定。

階段一：prepare 階段

1. Proposer 負(fù)責(zé)提出 proposal，每個(gè)提案者在提出提案時(shí)都會首先獲取到一個(gè) 具有全局唯一性的、遞增的提案編號N，即在整個(gè)集群中是唯一的編號 N，然后將該編號賦予其要提出的提案，在第一階段是只將提案編號發(fā)送給所有的表決者。

2. 如果一個(gè) Acceptor 收到一個(gè)編號為 N 的 Prepare 請求，如果小于它已經(jīng)響應(yīng)過的請求，則拒絕，不回應(yīng)或回復(fù)error。若 N 大于該 Acceptor 已經(jīng)響應(yīng)過的所有 Prepare 請求的編號（maxN），那么它就會將它已經(jīng)批準(zhǔn)過的編號最大的提案（如果有的話，如果還沒有的accept提案的話返回{pok，null，null}）作為響應(yīng)反饋給 Proposer，同時(shí)該 Acceptor 承諾不再接受任何編號小于 N 的提案

   eg：假定一個(gè) Acceptor 已經(jīng)響應(yīng)過的所有 Prepare 請求對應(yīng)的提案編號分別是1、2、…5和7，那么該 Acceptor 在接收到一個(gè)編號為8的 Prepare 請求后，就會將 7 的提案作為響應(yīng)反饋給 Proposer。

階段二：accept 階段

1. 如果一個(gè) Proposer 收到半數(shù)以上 Acceptor 對其發(fā)出的編號為 N 的 Prepare 請求的響應(yīng)，那么它就會發(fā)送一個(gè)針對 [N,V] 提案的 Accept 請求半數(shù)以上的 Acceptor。注意：V 就是收到的響應(yīng)中編號最大的提案的 value，如果響應(yīng)中不包含任何提案，那么 V 就由 Proposer 自己決定
2. 如果 Acceptor 收到一個(gè)針對編號為N的提案的Accept請求，只要該 Acceptor 沒有對編號大于 N 的 Prepare 請求做出過響應(yīng)，它就通過該提案。如果N小于 Acceptor 以及響應(yīng)的 prepare 請求，則拒絕，不回應(yīng)或回復(fù)error（當(dāng)proposer沒有收到過半的回應(yīng)，那么他會重新進(jìn)入第一階段，遞增提案號，重新提出prepare請求）
3. 最后是 Learner 獲取通過的提案（有多種方式）

paxos 算法的死循環(huán)問題

其實(shí)就有點(diǎn)類似于兩個(gè)人吵架，小明說我是對的，小紅說我才是對的，兩個(gè)人據(jù)理力爭的誰也不讓誰????。

比如說，此時(shí)提案者 P1 提出一個(gè)方案 M1，完成了 Prepare 階段的工作，這個(gè)時(shí)候 acceptor 則批準(zhǔn)了 M1，但是此時(shí)提案者 P2 同時(shí)也提出了一個(gè)方案 M2，它也完成了 Prepare 階段的工作。然后 P1 的方案已經(jīng)不能在第二階段被批準(zhǔn)了（因?yàn)?acceptor 已經(jīng)批準(zhǔn)了比 M1 更大的 M2），所以 P1 自增方案變?yōu)?M3 重新進(jìn)入 Prepare 階段，然后 acceptor ，又批準(zhǔn)了新的 M3 方案，它又不能批準(zhǔn) M2 了，這個(gè)時(shí)候 M2 又自增進(jìn)入 Prepare 階段。。。

就這樣無休無止的永遠(yuǎn)提案下去，這就是 paxos 算法的死循環(huán)問題。

ZAB

ZAB（Zookeeper Atomic Broadcast） 協(xié)議是為分布式協(xié)調(diào)服務(wù) Zookeeper 專門設(shè)計(jì)的一種支持崩潰恢復(fù)的原子廣播協(xié)議。

在 Zookeeper 中，主要依賴 ZAB 協(xié)議來實(shí)現(xiàn)分布式數(shù)據(jù)一致性，基于該協(xié)議，ZooKeeper 實(shí)現(xiàn)了一種主備模式的系統(tǒng)架構(gòu)來保持集群中各副本之間數(shù)據(jù)的一致性。

盡管 ZAB 不是 Paxos 的實(shí)現(xiàn)，但是 ZAB 也參考了一些 Paxos 的一些設(shè)計(jì)思想，比如：

• leader 向 follows 提出提案(proposal)
• leader 需要在達(dá)到法定數(shù)量(半數(shù)以上)的 follows 確認(rèn)之后才會進(jìn)行 commit
• 每一個(gè) proposal 都有一個(gè)紀(jì)元(epoch)號，類似于 Paxos 中的選票(ballot)

ZAB 中的三個(gè)角色

ZAB 中有三個(gè)主要的角色，Leader 領(lǐng)導(dǎo)者、Follower跟隨者、Observer觀察者 。

• Leader ：集群中 唯一的寫請求處理者 ，能夠發(fā)起投票（投票也是為了進(jìn)行寫請求）。

• Follower：能夠接收客戶端的請求，如果是讀請求則可以自己處理，如果是寫請求則要轉(zhuǎn)發(fā)給 Leader 。在選舉過程中會參與投票，有選舉權(quán)和被選舉權(quán) 。

• Observer ：就是沒有選舉權(quán)和被選舉權(quán)的 Follower 。

  在 ZAB 協(xié)議中對 zkServer(即上面我們說的三個(gè)角色的總稱) 還有兩種模式的定義，分別是消息廣播和崩潰恢復(fù)

消息廣播模式

1. Leader從客戶端收到一個(gè)事務(wù)請求（如果是集群中其他機(jī)器接收到客戶端的事務(wù)請求，會直接轉(zhuǎn)發(fā)給 Leader 服務(wù)器）
2. Leader 服務(wù)器生成一個(gè)對應(yīng)的事務(wù) Proposal，并為這個(gè)事務(wù)生成一個(gè)全局遞增的唯一的ZXID（通過其 ZXID 來進(jìn)行排序保證順序性）
3. Leader 將這個(gè)事務(wù)發(fā)送給所有的 Follows 節(jié)點(diǎn)
4. Follower 節(jié)點(diǎn)將收到的事務(wù)請求加入到歷史隊(duì)列(Leader 會為每個(gè) Follower 分配一個(gè)單獨(dú)的隊(duì)列先進(jìn)先出，順序保證消息的因果關(guān)系)中，并發(fā)送 ack 給 Leader
5. 當(dāng) Leader 收到超過半數(shù) Follower 的 ack 消息，Leader會廣播一個(gè) commit 消息
6. 當(dāng) Follower 收到 commit 請求時(shí)，會判斷該事務(wù)的 ZXID 是不是比歷史隊(duì)列中的任何事務(wù)的 ZXID 都小，如果是則提交，如果不是則等待比它更小的事務(wù)的 commit

崩潰恢復(fù)模式

ZAB 的原子廣播協(xié)議在正常情況下運(yùn)行良好，但天有不測風(fēng)云，一旦 Leader 服務(wù)器掛掉或者由于網(wǎng)絡(luò)原因?qū)е屡c半數(shù)的 Follower 的服務(wù)器失去聯(lián)系，那么就會進(jìn)入崩潰恢復(fù)模式。整個(gè)恢復(fù)過程結(jié)束后需要選舉出一個(gè)新的 Leader 服務(wù)器。

恢復(fù)模式大致可以分為四個(gè)階段：選舉、發(fā)現(xiàn)、同步、廣播

1. 當(dāng) leader 崩潰后，集群進(jìn)入選舉階段，開始選舉出潛在的新 leader(一般為集群中擁有最大 ZXID 的節(jié)點(diǎn))
2. 進(jìn)入發(fā)現(xiàn)階段，follower 與潛在的新 leader 進(jìn)行溝通，如果發(fā)現(xiàn)超過法定人數(shù)的 follower 同意，則潛在的新leader 將 epoc h加1，進(jìn)入新的紀(jì)元。新的 leader 產(chǎn)生
3. 集群間進(jìn)行數(shù)據(jù)同步，保證集群中各個(gè)節(jié)點(diǎn)的事務(wù)一致
4. 集群恢復(fù)到廣播模式，開始接受客戶端的寫請求

兩個(gè)特性

根據(jù) ZAB 消息廣播的過程可知，如果一個(gè)事務(wù) Proposal 在一臺機(jī)器上被處理成功，那么就應(yīng)該在所有的機(jī)器上處理成功，哪怕機(jī)器出現(xiàn)故障。所以在崩潰恢復(fù)過程結(jié)束后，為了保證新選舉出來的 Leader 服務(wù)器能正常工作，需要保證 2 個(gè)基本特性：

• 確保那些已經(jīng)在 Leader 服務(wù)器上提交的事務(wù)最終被所有的服務(wù)器都提交
• 確保丟棄那些只在 Leader 服務(wù)上被提出的事務(wù)

首先看第一個(gè)特性：確保那些已經(jīng)在 Leader 服務(wù)器上提交的事務(wù)最終被所有的服務(wù)器都提交。試想這么個(gè)場景：Leader 服務(wù)器在收到超半數(shù)的 ACK 返回響應(yīng)后，本應(yīng)該廣播 commit 消息，但這時(shí)候 Leader 服務(wù)器掛掉了（Leader 服務(wù)器已經(jīng)提交了事務(wù)），這時(shí)候就會導(dǎo)致 Follower 服務(wù)器和 Leader 服務(wù)器數(shù)據(jù)不一致的情況。ZAB 協(xié)議就須確保這種況下，所有的 Follower 服務(wù)器也都成功提交該事物。

第二個(gè)特性：確保丟棄那些只在 Leader 服務(wù)上被提出的事務(wù)。試想這么個(gè)場景：Leader 服務(wù)器在生成 Proposal 后就掛掉了，其他的服務(wù)器都沒收到該 Proposal。于是，當(dāng)該機(jī)器再次加入集群中的時(shí)候，需要確保丟棄該事物 Proposal。

所以上面兩個(gè)特性總結(jié)就是下面兩句話：

• 提交已經(jīng)被 Leader 提交的事務(wù)
• 丟棄已經(jīng)被跳過的事務(wù)

基于這兩個(gè)特性，如果讓新選舉出來的 Leader 具有最大的 ZXID 的事務(wù) Proposal，那么就可以保證該 Leader 一定具有所有已提交的提案。更為重要的是，如果讓具有最高 ZXID 的事務(wù) Proposal 的機(jī)器來成為 Leader，就可以省去 Leader 服務(wù)器檢查 Proposal 的提交和丟棄工作這一步操作了。

數(shù)據(jù)同步

在完成 Leader 選舉之后，在正式開始工作（即接收客戶端的事務(wù)請求，然后提出新的提案）之前，Leader 服務(wù)器首先會確保事務(wù)日志中的所有 Proposal 是否都已經(jīng)被集群中過半的機(jī)器提交了，即是否完成數(shù)據(jù)同步。

對于那些沒有被 Follower 服務(wù)器提交的事務(wù)，Leader 會為每個(gè) Follower 服務(wù)器準(zhǔn)備一個(gè)隊(duì)列，并將那些沒有被各 Follower 服務(wù)器同步的事務(wù)已 Proposal 消息的形式逐個(gè)發(fā)送給 Follower 服務(wù)器，并在每一個(gè) Proposal 消息后面緊接著再發(fā)送一個(gè) commit 消息，以表示該事務(wù)已被提交。等到 Follower 服務(wù)器將所有未同步的事務(wù) Proposal 都從 Leader 服務(wù)器上同步過來并應(yīng)用到本地?cái)?shù)據(jù)庫，Leader 服務(wù)器就將該 Follower 服務(wù)器加入到真正可用的 Follower 列表中。

那 ZAB 是如何處理那些需要被丟棄的事務(wù) Proposal 呢？

ZXID 是一個(gè) 64 位的數(shù)字，其中低 32 位可看作是計(jì)數(shù)器，Leader 服務(wù)器每產(chǎn)生一個(gè)新的事務(wù) Proposal 的時(shí)候，都會該計(jì)數(shù)器進(jìn)行加 1 操作。而高 32 位表示 Leader 周期 epoch 的編號，每當(dāng)選舉一個(gè)新的 Leader 服務(wù)器，就會從該服務(wù)器本地的事務(wù)日志中最大 Proposal 的 ZXID 中解析出對應(yīng)的 epoch 值，然后對其加 1 操作，這個(gè)值就作為新的 epoch 值，并將低 32 位初始化為 0 來開始生成新的 ZXID。

基于這樣的策略，當(dāng)一個(gè)包含上一個(gè) Leader 周期中尚未提交的事務(wù) Proposal 的服務(wù)器啟動(dòng)時(shí)，以 Follower 角色加入集群中之后，Leader 服務(wù)器會根據(jù)自己服務(wù)器上最后被提交的 Proposal 來和 Follower 服務(wù)器的 Proposal 進(jìn)行比對，比對結(jié)果就是 Leader 會要求 Follower 進(jìn)行一個(gè)回退操作——回退到一個(gè)確實(shí)已經(jīng)被集群中過半機(jī)器提交的最新的事務(wù) Proposal。

Master 選舉實(shí)現(xiàn)細(xì)節(jié)

上文說過，新選舉出來的 Leader 具有最大的 ZXID 的事務(wù) Proposal，那這是怎么實(shí)現(xiàn)的呢？

ZAB 默認(rèn)采用 TCP 版本的 FastLeaderElection 選舉算法。在選舉投票消息中包含了兩個(gè)最基本的信息：所推舉的服務(wù)器 SID 和 ZXID，分別表示被推舉服務(wù)器的唯一標(biāo)識（每臺機(jī)器不一樣）和事務(wù) ID。假如投票信息為 （SID, ZXID）的形式。在第一次投票的時(shí)候，由于還無法檢測集群其他機(jī)器的狀態(tài)信息，因此每臺機(jī)器都將自己作為被推舉的對象來進(jìn)行投票。每次對收到的投票，都是一個(gè)對投票信息（SID, ZXID）對比的過程，規(guī)則如下：

• 如果接收到的投票 ZXID 大于自己的 ZXID，就認(rèn)可當(dāng)前收到的投票，并再次將該投票發(fā)送出去。
• 如果 ZXID 小于自己的 ZXID，那么就堅(jiān)持的投票，不做任何變更。
• 如果 ZXID 等于自己的 ZXID，再對比 SID，比自己大，就認(rèn)可當(dāng)前收到的投票，再將該投票發(fā)送出去；如果比自己小，那就堅(jiān)持自己的投票，不做變更。

經(jīng)過第二次投票后，集群中每臺機(jī)器都會再次收到其他機(jī)器的投票，然后開始統(tǒng)計(jì)，如果一臺機(jī)器收到超過了半數(shù)的相同投票，那么這個(gè)投票對應(yīng)的 SID 機(jī)器即為 Leader。

將該投票發(fā)送出去。

• 如果 ZXID 小于自己的 ZXID，那么就堅(jiān)持的投票，不做任何變更。
• 如果 ZXID 等于自己的 ZXID，再對比 SID，比自己大，就認(rèn)可當(dāng)前收到的投票，再將該投票發(fā)送出去；如果比自己小，那就堅(jiān)持自己的投票，不做變更。

經(jīng)過第二次投票后，集群中每臺機(jī)器都會再次收到其他機(jī)器的投票，然后開始統(tǒng)計(jì)，如果一臺機(jī)器收到超過了半數(shù)的相同投票，那么這個(gè)投票對應(yīng)的 SID 機(jī)器即為 Leader。

簡單來說，通常哪臺服務(wù)器上的數(shù)據(jù)越新，那么越有可能成為 Leader。原因很簡答，數(shù)據(jù)越新，也就越能夠保證數(shù)據(jù)的恢復(fù)。當(dāng)然，如果集群中有幾個(gè)服務(wù)器具有相同的 ZXID，那么 SID 較大的那臺服務(wù)器成為 Leader。文章來源地址http://www.zghlxwxcb.cn/news/detail-776505.html

到了這里，關(guān)于分布式「走進(jìn)分布式一致性協(xié)議」從2PC、3PC、Paxos 到 ZAB的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！