分佈式：分佈式事務（CAP、兩階段提交、三階段提交）

1 關於分佈式系統

1.1 介紹

我們常見的單體結構的集中式系統，一般整個項目就是一個獨立的應用，所有的模塊都聚合在一起。明顯的弊端就是不易擴展、發佈冗重、服務治理不好做。

所以我們把整個系統拆分成若干個具備獨立運行能力的計算服務的集合，而從用戶的角度看，是一個完整的系統，但實際上，它是一個分佈式服務的集合。

分佈式系統主要從以下幾個方面進行裂變：

1.2 優勢和不足

分佈式系統可以解決集中式不便擴展的弊端，提供了便捷的擴展性、獨立的服務治理，並提高了安全可靠性。隨着微服務技術（Spring Cloud、Dubbo） 以及容器技術（Kubernetes、Docker）的大熱，分佈式技術發展非常迅速。

不足的地方：分佈式系統雖好，也帶來了系統的複雜性，如分佈式事務、分佈式鎖、分佈式 session、數據一致性等都是現在分佈式系統中需要解決的難題，雖然已經有很多成熟的方案，但都不完美。

分佈式系統的便利，其實是犧牲了一些開發、測試、運維 成本的，讓工作量增加了，所以分佈式系統管理不好反而會變成一種負擔。

2 分佈式事務

分佈式事務就是指事務的參與者、支持事務的服務器、資源服務器以及事務管理器分別位於不同的分佈式系統的不同節點之上。

分佈式場景下一次完整的操作由不同的 action 組成，這些 actions 可能分佈在不同的服務器上，且屬於不同的應用，分佈式事務需要保證這些 action 要麼全部成功，要麼全部失敗。保證單個完整操作的原子性。

本質上來說，分佈式事務就是爲了保證不同數據庫的數據一致性。

2.1 CAP 理論

CAP 定理（也稱爲 Brewer 定理），指的是在分佈式計算環境下，有 3 個核心的需求：

1、一致性（Consistency）：再分佈，所有實例節點同一時間看到是相同的數據

2、可用性（Availability）：不管是否成功，確保每一個請求都能接收到響應

3、分區容錯性（Partition Tolerance）：系統任意分區後，在網絡故障時，仍能操作

CAP 理論告訴我們，分佈式系統不可能同時滿足以下三種。最多隻能同時滿足其中的兩項，因爲很多時候 P 是必須的, 因此往往選擇就在 CP 或者 AP 中

2.2 CAP 的組合情況

CA: 放棄分區容錯性。非分佈式架構，比如關係數據庫，因爲沒有分區，但是在分佈式系統下，CA 組合就不建議了。

AP: 放棄強一致性。追求最終一致性，類似的場景比如轉賬，可以接受兩小時後到賬，Eureka 的註冊也是類似的做法。 

CP: 放棄可用性。zookeeper 在 leader 宕機後，選舉期間是不提供服務的。類似的場景比如支付完成之後出訂單，必須一進一出都完成纔行。 

結論：在分佈式系統中 AP 運用的最多，因爲他放棄的是強一致性，追求的是最終一致性，性價比最高

 

2.3 數據一致性模型

分佈式系統通過同步數據的副本來提高系統的可靠性和容錯性，而且數據的不同的副本，合理會存在不同的機器或集羣上。

強一致性：
當用戶的操作完成之後，會立馬被同步到不同的數據副本中，後續其他任意請求都會獲得更新過的值。這種對用戶的可見性是最友好的，能始終保證讀到正確的值。根據 CAP 理論，這種實現需要犧牲可用性。

弱一致性：
系統並不保證所有請求的訪問都會獲得最新值。數據寫入成功之後，不承諾立即可以讀，也不承諾具體多久之後可以讀到，甚至讀不到。在請求獲得數據更新的這段時間，我 i 們稱之爲 “不一致性窗口”。

最終一致性：
是弱一致性的一種。系統保證在沒有後續更新的前提下，系統最終返回上一次更新操作的值。在沒有故障發生的前提下，不一致窗口的時間主要受通信延遲，系統負載和複製副本的個數影響。

**常見的事務處理機制： **

1、Master-Slave 複製：寫請求由 Master 負責，寫入 Master 後，由 Master 同步到 Slave 上。

異步同步，所以是弱 / 最終一致性。

2、Master-Master 主主複製

異步同步，最終的一致性，多個節點間需要序列化協議。

2.4 分佈式事務應用場景

2.4.1 典型支付場景

這是最經典的場景。支付過程，要先對買家賬戶進行扣款，同時對賣家賬戶進行付款，

像這類的操作，必須在一個事務中執行，保證原子性，要麼都成功，要麼都不成功。但是往往買家的支付平臺和賣家的支付平臺不一致，即使都在一個平臺下，所屬的業務服務和數據服務

（歸屬不同表甚至不同庫，比如賣家中心庫、賣家中心庫）也不是同一個。針對於不同的業務平臺、不同的數據庫做操作必然要引入分佈式事務。

2.4.2 在線下單

同理，買家在電商平臺下單，往往會涉及到兩個動作，一個是扣庫存，第二個是更新訂單狀態，庫存和訂單一般屬於不同的數據庫，需要使用分佈式事務保證數據一致性。

2.4.3 跨行轉賬

跨行轉賬問題也是一個典型的分佈式事務，用戶 A 同學向 B 同學的賬戶轉賬 500，要先進行 A 同學的賬戶 - 500，然後 B 同學的賬戶 + 500，既然是不同的銀行，

 

2.5 常見分佈式一致性保障（分佈式事務解決方案）

2.5.1 XA 兩階段提交協議

兩階段提交協議（Two-phase commit protocol），簡稱 2PC，過程涉及到協調者和參與者。

它是一種強一致性設計，引入一個事務協調者的角色來協調管理各參與者的提交和回滾，二階段分別指的是準備（投票）和提交兩個階段。

第一階段（準備階段）

爲事務協調者的節點會首先向所有的參與者節點發送 Prepare 請求。

在接到 Prepare 請求之後，每一個參與者節點會各自執行與事務有關的數據更新，寫入 Undo Log（撤銷）和 Redo Log（重做）。

如果參與者執行成功，暫時不提交事務，而是向事務協調節點返回 “完成” 消息。當事務協調者接到了所有參與者的返回消息，整個分佈式事務將會進入第二階段。

假如在第一階段有一個參與者返回失敗，那麼協調者就會向所有參與者發送回滾事務的請求，即分佈式事務執行失敗。如下圖:

第二階段（提交階段）

如果事務協調節點在之前所收到都是正向返回，那麼它將會向所有事務參與者發出 Commit 請求。

接到 Commit 請求之後，事務參與者節點會各自進行本地的事務提交，並釋放鎖資源。當本地事務完成提交後，將會向事務協調者返回 “完成” 消息。

當事務協調者接收到所有事務參與者的 “完成” 反饋，整個分佈式事務完成。

當有一個 Commit 不成功，那其他的應該也是提交不成功的。

2.5.2 XA 三階段提交

三階段提交：CanCommit 階段、PreCommit 階段、DoCommit 階段，簡稱 3PC

三階段提交協議（Three-phase commit protocol，3PC），是二階段提交（2PC）的改進版本。與兩階段提交不同的是，三階段提交有兩個改動點：

引入超時機制。同時在協調者和參與者中都引入超時機制。

在第一階段和第二階段中插入一個準備階段。保證了在最後提交階段之前各參與節點的狀態是一致的。

即 3PC 把 2PC 的準備階段再次一分爲二，這樣三階段提交就有 CanCommit、PreCommit、DoCommit 三個階段。當 CanCommit、PreCommit、DoCommit

的任意一個步驟失敗或者等待超時，執行 RollBack。

 

2.5.3 MQ 事務

利用消息中間件來異步完成事務的後半部分更新，實現系統的最終一致性。這個方式避免了像 XA 協議那樣的性能問題。

下面的圖中，使用 MQ 完成事務在分佈式的另外一個子系統上的操作，保證了動作一致性。

           

2.5.4 TCC 事務

TCC 事務是 Try、Confirm、Cancel 三種指令的縮寫，其邏輯模式類似於 XA 兩階段提交，但是實現方式是在代碼層面人爲實現。2PC 和 3PC 都是數據庫層面的，而 TCC 是業務層面的分佈式事務。

分佈式事務除了上面提到的數據庫層面的操作外，還包括髮送短信、郵件這種業務操作等，這時候 TCC 就有用武之地了！

圖中就是一個典型的分佈式系統的原子性操作，涉及 A、B、C 三個服務的執行。如果有一個服務 try 出問題，整個事務管理器就執行 calcel，如果三個 try 都成功，才執行 confirm 做正式提交。

2.5.5 最終補償機制，同於 MQ 事務

最後使用補償機制做最後的一致性保障，MQ 方案儘量使用補償機制進行保障。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/QM7lzsHY8RLgd1wQz5hrSQ

猜你喜歡