1.前言

前面一篇文章和大家一起學習了下分布式系統(tǒng)一致性問題的一些理論，其中重點是理解 PACELC理論、 BASE理論等問題，讓我們對于分布式一致性的重點是什么有一些認識。

在了解分布式一致性的理論和概念之后，后續(xù)將和大家一起討論分布式一致性協(xié)議，其中包括： 2PC、3PC、Paoxs協(xié)議、Raft協(xié)議。

篇幅有限，本文重點展開2PC協(xié)議，后續(xù)文章繼續(xù)深入。

圖(網(wǎng)絡)|NASA合成的銀河系中心區(qū)域圖像

2. 單機事務和分布式事務

在聊2PC和3PC之前，我們有必要先了解下 單機事務和 分布式事務。

事務是一組原子操作， 要么全成功要么全失敗 All or Nothing，否則就會出現(xiàn)數(shù)據(jù)混亂，這種需求在 金融和電商領域很普遍。

試想你去天貓買了臺mac，訂單服務、扣款服務、庫存服務出現(xiàn)任何一個環(huán)節(jié)的失敗都會帶來問題，所以就需要事務來做保證， 一榮俱榮一損俱損。

單機事務具備ACID特性，大家都比較喜歡，但是單機的能力畢竟有限，我們常常必須在分布式場景下同樣完成這一組原子操作，也就是分布式事務。

由于分布式系統(tǒng)中各個子服務是部署在 不同的物理節(jié)點上， 不同交換機、 不同機房、不同城市，這樣以來，要想 像單機系統(tǒng)一樣完成這一組原子操作就沒那么容易了，因此就出現(xiàn)了很多分布式一致性協(xié)議和算法，來解決分布式事務問題保證數(shù)據(jù)一致性。

分布式系統(tǒng)的各個節(jié)點只能依靠 網(wǎng)絡來進行數(shù)據(jù)通信，但是網(wǎng)絡往往 并不完全可靠，同時節(jié)點 物理故障也時常發(fā)生，在這樣一個 復雜的環(huán)境中去保證數(shù)據(jù)一致性確實不太容易。

3.一致性協(xié)議的一些思路

突兀地去學習一個新的協(xié)議或者算法往往比較生硬，不如思考一下生活現(xiàn)象，大部分的計算機領域的算法和思想在實際生活中都有映像，又或者說 算法來源于生活。

舉個栗子：在規(guī)模盛大的閱兵儀式中會有陸?？斩啾N多方隊，為了讓命令和節(jié)奏準確地下達，我們 需要樂曲、指揮、領隊、排頭、隊員等多種角色。整個活動需要在不同角色的相互作用之下，才能讓一個數(shù)量龐大的個體組成一個整體來完成一個目標。

再舉個栗子：2018年5月在西安舉行了一場盛大的 無人機編組飛行燈光秀，共計1374架無人機組成一個龐大的編組來完成燈光表演，但是還是出現(xiàn)了問題，并未上演完美圖案：

圖(網(wǎng)絡)|西安無人機編組飛行燈光秀

分布式系統(tǒng)也是如此，為了讓很多參與的機器節(jié)點節(jié)奏步調(diào)一致，我們就需要不同的角色各司其職，共同完成一項任務，但是仍然困難重重，因為會有網(wǎng)絡故障和節(jié)點物理故障等問題。

4. 2PC二階段提交協(xié)議基本過程

要理解2PC協(xié)議重點在于節(jié)點角色分工和兩個階段所執(zhí)行的動作以及不同情況下的處理邏輯。

2PC協(xié)議總體概覽

4.1 節(jié)點角色

二階段提交協(xié)議將節(jié)點分為： 協(xié)調(diào)者和 參與者，對于者兩種角色，當然你也可以理解為 Leader和大頭兵。

• 協(xié)調(diào)者Leader
  負責向參與者發(fā)送指令，收集參與者反饋，做出提交或者回滾決策
• 參與者大頭兵
  接收協(xié)調(diào)者的指令執(zhí)行事務操作，向協(xié)調(diào)者反饋操作結(jié)果，并繼續(xù)執(zhí)行協(xié)調(diào)者發(fā)送的最終指令

4.2 兩個階段

2PC協(xié)議分為： 準備階段和 提交階段。

4. 2.1 準備 階 段

協(xié)調(diào)者向所有參與者節(jié)點發(fā)送詢問并執(zhí)行事務的命令，參與者節(jié)點收到命令后根據(jù)自己的狀態(tài)執(zhí)行或者不執(zhí)行事務，并將動作記錄下來，最后將對命令的處理結(jié)果反饋給協(xié)調(diào)者。

圖|準備階段的三個環(huán)節(jié)

1詢問環(huán)節(jié)：協(xié)調(diào)者向參與者詢問，是否準備好可以執(zhí)行事務，之后協(xié)調(diào)者開始等待各參與者的響應，這個環(huán)節(jié)協(xié)調(diào)者處于阻塞等待狀態(tài)。

2處理環(huán)節(jié)：參與者收到協(xié)調(diào)者的詢問后根據(jù)自身情況來決定是否執(zhí)行事務操作，如果參與者執(zhí)行事務成功，將Undo和Redo信息記入事務日志，但不提交事務；否則直接返回失敗。

3響應環(huán)節(jié)：當參與者成功執(zhí)行了事務操作，就反饋yes給協(xié)調(diào)者，表示事務在本地執(zhí)行；當參與者沒有成功執(zhí)行事務，就反饋no給協(xié)調(diào)者，表示事務不可以執(zhí)行提交，這部分反饋對于協(xié)調(diào)者決策下個階段起到非常重要的作用。

4.2.2 準備階段

協(xié)調(diào)者根據(jù)準備階段收到的參與者反饋來決定最終提交事務或者中斷回滾事務，具體來說，當協(xié)調(diào)者在準備階段結(jié)束時收到的響應反饋有一個no，那么就中斷事務，如果收到的反饋全部是yes就提交事務。

情況一: 提交事務 

如果在準備階段結(jié)束時，協(xié)調(diào)者收到了來自所有參與者的yes反饋，接下來協(xié)調(diào)者就會向所有參與者發(fā)送提交事務指令，具體的過程如下：

步驟1. 協(xié)調(diào)者向所有參與者發(fā)送事務提交消息Commit命令

步驟2. 參與者在收到來自協(xié)調(diào)者的Commit命令之后，執(zhí)行事務提交動作，并釋放事務期間所有持有的鎖和資源，這一步很重要

步驟3. 所有參與者在執(zhí)行本地事務且釋放資源完成后，向協(xié)調(diào)者發(fā)送事務提交確認消息ACK

步驟4. 協(xié)調(diào)者在收到所有參與者的ACK消息后確認完成本次事務

情況二: 回滾事務 

如果在準備階段結(jié)束時，協(xié)調(diào)者 沒有收到來自所有參與者的yes反饋，接下來協(xié)調(diào)者就會向所有參與者發(fā)送 回滾事務指令，具體的過程如下：

步驟1. 協(xié)調(diào)者向所有參與者發(fā)送事務回滾消息Rollback

步驟2. 參與者收到Rollback回滾指令后，根據(jù)本地的回滾日志來撤銷階段一執(zhí)行的事務，并釋放事務期間所有持有的鎖和資源

步驟3. 所有參與者在完成指令后向協(xié)調(diào)者回復反饋ACK

步驟4. 協(xié)調(diào)者在收到所有參與者的ACK確認消息后撤銷該事務

通過上面的描述我們知道了，2PC協(xié)議通過將節(jié)點分為不同的角色，進行兩個階段的處理來執(zhí)行分布式事務，但是難免要去想2PC協(xié)議可以真正解決分布式數(shù)據(jù)一致問題嗎？

5. 2PC協(xié)議的異常分析

前面的兩個階段涉及了多次協(xié)調(diào)者和參與者的網(wǎng)絡通信交互，但是我們都知道 網(wǎng)絡是不可靠的， 節(jié)點也能出現(xiàn)故障，因此必須要考慮異常情況下2PC協(xié)議是否仍然可以正常工作。

故障可以分為很多種： 可恢復機器故障和 不可恢復機器故障、 網(wǎng)絡正常抖動故障、 網(wǎng)絡分區(qū)故障等多種情況。

2PC整個過程交互也很多， 不同階段發(fā)生不同故障造成的結(jié)果也是不一樣的，顯然 這是個m*n的組合問題，不同的異常情況會產(chǎn)生不同的結(jié)果要完全列出來并分析絕非易事，我們找其中幾個重點異常來做分析。

從前面的分析我們知道，在準備階段本質(zhì)上是不會提交事務數(shù)據(jù)的，即使發(fā)生故障也可以根據(jù)日志來進行回滾，所以不會產(chǎn)生數(shù)據(jù)不一致的問題，但是在提交階段提交事務的情況下由于可能已經(jīng)有參與者提交了事務數(shù)據(jù)，因此可能出現(xiàn)數(shù)據(jù)不一致，這個是要重點分析的階段。

注：以下所說的參與者故障并非指全部的參與者，而是其中1個或者幾個。

• 協(xié)調(diào)者故障&參與者正常

協(xié)調(diào)者作為系統(tǒng)的領導者角色，由于協(xié)調(diào)者是單點的在任何過程出現(xiàn)異常都需要重點處理，發(fā)生不可恢復的物理故障時，選舉出新的協(xié)調(diào)者來接替之前的工作，這時新協(xié)調(diào)者就需要向所有參與者詢問當前的階段和處理進度，但是如果只是出現(xiàn)網(wǎng)絡分區(qū)協(xié)調(diào)者暫時失聯(lián)，就可能出現(xiàn)腦裂的情況。

• 協(xié)調(diào)者正常&參與者故障

由于協(xié)調(diào)者做決策需要依據(jù)參與者的反饋，出現(xiàn)參與者故障會造成協(xié)調(diào)者決策困難，如果參與者的故障是可恢復的，在短時間內(nèi)恢復后則向協(xié)調(diào)者詢問自己需要做什么，從而跟上節(jié)奏，如果時間過長或者是不可恢復故障，那么協(xié)調(diào)者就會回滾本次事務。

• 協(xié)調(diào)者故障&參與者故障(重點)

協(xié)調(diào)者在提交階段會向所有參與者發(fā)送指令，假定在 協(xié)調(diào)者發(fā)送第一條指令之后掛掉，此時 只有一個參與者接收到了指令并執(zhí)行后也掛掉了， 其他 參與者并沒有收到指令。

新選舉出來的協(xié)調(diào)者詢問所有參與節(jié)點狀態(tài)時，如果 已經(jīng)掛掉的參與者恢復了，那么狀態(tài)就明確了commit或者rollback，如果掛掉的 參與者并沒有恢復并且已經(jīng)執(zhí)行了commit/rollback操作，那么將會 出現(xiàn)數(shù)據(jù)不一致，并且新的協(xié)調(diào)者由于沒有獲得足夠的信息無法明確當前的狀態(tài)，其他的參與者在階段一執(zhí)行后 產(chǎn)生阻塞。

• 網(wǎng)絡故障

網(wǎng)絡分區(qū)是個很棘手的問題，極端情況下可能出現(xiàn)幾個分區(qū)，不同分區(qū)中有獨自的參與者和協(xié)調(diào)者。

綜上可知，2PC協(xié)議在協(xié)調(diào)者和參與者都掛掉的時候會出現(xiàn)數(shù)據(jù)不一致，并且在正常的交互過程中會有阻塞情況，以及協(xié)調(diào)者單點的問題。

6.2PC協(xié)議的優(yōu)缺點

2PC協(xié)議的原理簡單，實現(xiàn)方便，但是存在 同步阻塞、 單點問題、 網(wǎng)絡 分區(qū)腦裂、極端情況 數(shù)據(jù)不一致的問題，我們具體展開一下。

2PC在準備階段等待參與者響應反饋時是同步阻塞的，在實際網(wǎng)絡中可能會導致長時間阻塞的問題，因為我們無法保證所有參與者網(wǎng)絡的順暢。

協(xié)調(diào)者在整個兩階段中作用很大，但是存在單點問題，一旦出現(xiàn)協(xié)調(diào)者故障，所有的參與者都將處于阻塞資源無法釋放的情況，從而影響其他操作的進行。

2PC協(xié)議整個過程中基于所有參與者的反饋，但是由于異常情況的存在，在一些時候很難達成一致從而回滾事務，整個策略容錯性不強，并且網(wǎng)絡分區(qū)的存在可能產(chǎn)生腦裂造成分區(qū)數(shù)據(jù)不一致。

7.小結(jié)

本文對從單機事務和分布式事務的剛需作為切入點，描述了分布式數(shù)據(jù)一致性的難點和基本解決思路，重點闡述了2PC協(xié)議準備階段和提交階段的詳細過程，最后對2PC協(xié)議的異常情況做出分析并給出2PC協(xié)議的優(yōu)缺點。

8.巨人的肩膀

• https://www.cnblogs.com/sunsky303/p/9290992.html
• https://segmentfault.com/q/1010000014439562
• https://www.cnblogs.com/shangxiaofei/p/5196260.html