本文轉載自微信公眾號「 后端技術指南針」，轉載本文請聯系 后端技術指南針公眾號。

1.前言

在了解分布式一致性的理論和概念之后，后續將和大家一起討論分布式一致性協議，其中包括：2PC、3PC、Paoxs協議、Raft協議。篇幅有限，本文重點展開2PC協議，后續文章繼續深入。

[[325517]]

圖(網絡)|NASA合成的銀河系中心區域圖像

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

在聊2PC和3PC之前，我們有必要先了解下單機事務和分布式事務。事務是一組原子操作，要么全成功要么全失敗 All or Nothing，否則就會出現數據混亂，這種需求在金融和電商領域很普遍。試想你去天貓買了臺mac，訂單服務、扣款服務、庫存服務出現任何一個環節的失敗都會帶來問題，所以就需要事務來做保證，一榮俱榮一損俱損。

單機事務具備ACID特性，大家都比較喜歡，但是單機的能力畢竟有限，我們常常必須在分布式場景下同樣完成這一組原子操作，也就是分布式事務。由于分布式系統中各個子服務是部署在不同的物理節點上，不同交換機、不同機房、不同城市，這樣以來，要想像單機系統一樣完成這一組原子操作就沒那么容易了，因此就出現了很多分布式一致性協議和算法，來解決分布式事務問題保證數據一致性。分布式系統的各個節點只能依靠網絡來進行數據通信，但是網絡往往并不完全可靠，同時節點物理故障也時常發生，在這樣一個復雜的環境中去保證數據一致性確實不太容易。

3.一致性協議的一些思路

突兀地去學習一個新的協議或者算法往往比較生硬，不如思考一下生活現象，大部分的計算機領域的算法和思想在實際生活中都有映像，又或者說算法來源于生活。舉個栗子：在規模盛大的閱兵儀式中會有陸海空多兵種多方隊，為了讓命令和節奏準確地下達，我們需要樂曲、指揮、領隊、排頭、隊員等多種角色。整個活動需要在不同角色的相互作用之下，才能讓一個數量龐大的個體組成一個整體來完成一個目標。再舉個栗子：2018年5月在西安舉行了一場盛大的無人機編組飛行燈光秀，共計1374架無人機組成一個龐大的編組來完成燈光表演，但是還是出現了問題，并未上演完美圖案：

[[325520]]

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

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

4. 2PC二階段提交協議基本過程

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

2PC協議總體概覽

4.1 節點角色

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

• 協調者Leader

負責向參與者發送指令，收集參與者反饋，做出提交或者回滾決策

• 參與者大頭兵

接收協調者的指令執行事務操作，向協調者反饋操作結果，并繼續執行協調者發送的最終指令

4.2 兩個階段

2PC協議分為：準備階段和提交階段。

4.2.1 準備階段

協調者向所有參與者節點發送詢問并執行事務的命令，參與者節點收到命令后根據自己的狀態執行或者不執行事務，并將動作記錄下來，最后將對命令的處理結果反饋給協調者。

圖|準備階段的三個環節

1詢問環節：協調者向參與者詢問，是否準備好可以執行事務，之后協調者開始等待各參與者的響應，這個環節協調者處于阻塞等待狀態。

2處理環節：參與者收到協調者的詢問后根據自身情況來決定是否執行事務操作，如果參與者執行事務成功，將Undo和Redo信息記入事務日志，但不提交事務;否則直接返回失敗。

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

4.2.2 準備階段

協調者根據準備階段收到的參與者反饋來決定最終提交事務或者中斷回滾事務，具體來說，當協調者在準備階段結束時收到的響應反饋有一個no，那么就中斷事務，如果收到的反饋全部是yes就提交事務。情況一: 提交事務 如果在準備階段結束時，協調者收到了來自所有參與者的yes反饋，接下來協調者就會向所有參與者發送提交事務指令，具體的過程如下：

步驟1. 協調者向所有參與者發送事務提交消息Commit命令

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

步驟3. 所有參與者在執行本地事務且釋放資源完成后，向協調者發送事務提交確認消息ACK

步驟4. 協調者在收到所有參與者的ACK消息后確認完成本次事務

情況二: 回滾事務 如果在準備階段結束時，協調者沒有收到來自所有參與者的yes反饋，接下來協調者就會向所有參與者發送回滾事務指令，具體的過程如下：

步驟1. 協調者向所有參與者發送事務回滾消息Rollback

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

步驟3. 所有參與者在完成指令后向協調者回復反饋ACK

步驟4. 協調者在收到所有參與者的ACK確認消息后撤銷該事務

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

5. 2PC協議的異常分析

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

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

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

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

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

• 協調者故障&參與者正常

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

• 協調者正常&參與者故障

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

• 協調者故障&參與者故障(重點)

協調者在提交階段會向所有參與者發送指令，假定在協調者發送第一條指令之后掛掉，此時只有一個參與者接收到了指令并執行后也掛掉了，其他參與者并沒有收到指令。新選舉出來的協調者詢問所有參與節點狀態時，如果已經掛掉的參與者恢復了，那么狀態就明確了commit或者rollback，如果掛掉的參與者并沒有恢復并且已經執行了commit/rollback操作，那么將會出現數據不一致，并且新的協調者由于沒有獲得足夠的信息無法明確當前的狀態，其他的參與者在階段一執行后產生阻塞。

• 網絡故障

網絡分區是個很棘手的問題，極端情況下可能出現幾個分區，不同分區中有獨自的參與者和協調者。綜上可知，2PC協議在協調者和參與者都掛掉的時候會出現數據不一致，并且在正常的交互過程中會有阻塞情況，以及協調者單點的問題。

6.2PC協議的優缺點

2PC協議的原理簡單，實現方便，但是存在同步阻塞、單點問題、網絡分區腦裂、極端情況數據不一致的問題，我們具體展開一下。2PC在準備階段等待參與者響應反饋時是同步阻塞的，在實際網絡中可能會導致長時間阻塞的問題，因為我們無法保證所有參與者網絡的順暢。協調者在整個兩階段中作用很大，但是存在單點問題，一旦出現協調者故障，所有的參與者都將處于阻塞資源無法釋放的情況，從而影響其他操作的進行。2PC協議整個過程中基于所有參與者的反饋，但是由于異常情況的存在，在一些時候很難達成一致從而回滾事務，整個策略容錯性不強，并且網絡分區的存在可能產生腦裂造成分區數據不一致。

7.小結

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

8.巨人的肩膀

https://www.cnblogs.com/sunsky303/p/9290992.html

https://segmentfault.com/q/1010000014439562

https://www.cnblogs.com/shangxiaofei/p/5196260.html