站長資訊網
隨著業務的快速發展、業務復雜度越來越高，幾乎每個公司的系統都會從單體走向分布式，特別是轉向微服務架構。隨之而來就必然遇到分布式事務這個難題。
這篇文章首先介紹了相關的基礎理論，然后總結了最經典的事務方案，最后給出了子事務亂序執行（冪等、空補償、懸掛問題）的解決方案，分享給大家。
基礎理論
在講解具體方案之前，我們先了解一下分布式事務所涉及到的基礎理論知識。
我們拿轉賬作為例子，A需要轉100元給B，那么需要給A的余額-100元，給B的余額+100元，整個轉賬要保證，A-100和B+100同時成功，或者同時失敗。看看在各種場景下，是如何解決這個問題的。
事務
把多條語句作為一個整體進行操作的功能，被稱為數據庫事務。數據庫事務可以確保該事務范圍內的所有操作都可以全部成功或者全部失敗。
事務具有 4 個屬性：原子性、一致性、隔離性、持久性。這四個屬性通常稱為 ACID 特性。
- Atomicity（原子性）：一個事務中的所有操作，要么全部完成，要么全部不完成，不會結束在中間某個環節。事務在執行過程中發生錯誤，會被恢復到事務開始前的狀態，就像這個事務從來沒有執行過一樣。
- Consistency（一致性）：在事務開始之前和事務結束以后，數據庫的完整性沒有被破壞。完整性包括外鍵約束、應用定義的等約束不會被破壞。
- Isolation（隔離性）：數據庫允許多個并發事務同時對其數據進行讀寫和修改的能力，隔離性可以防止多個事務并發執行時由于交叉執行而導致數據的不一致。
- Durability（持久性）：事務處理結束后，對數據的修改就是永久的，即便系統故障也不會丟失。
假如我們的業務系統不復雜，可以在一個數據庫、一個服務內對數據進行修改，完成轉賬，那么，我們可以利用數據庫事務，保證轉賬業務的正確完成。
分布式事務
銀行跨行轉賬業務是一個典型分布式事務場景，假設A需要跨行轉賬給B，那么就涉及兩個銀行的數據，無法通過一個數據庫的本地事務保證轉賬的ACID，只能夠通過分布式事務來解決。
分布式事務就是指事務的發起者、資源及資源管理器和事務協調者分別位于分布式系統的不同節點之上。在上述轉賬的業務中，用戶A-100操作和用戶B+100操作不是位于同一個節點上。本質上來說，分布式事務就是為了保證在分布式場景下，數據操作的正確執行。
分布式事務在分布式環境下，為了滿足可用性、性能與降級服務的需要，降低一致性與隔離性的要求，一方面遵循 BASE 理論（BASE相關理論，涉及內容非常多，感興趣的同學，可以參考BASE理論）：
- 基本業務可用性（Basic Availability）
- 柔性狀態（Soft state）
- 最終一致性（Eventual consistency）
同樣的，分布式事務也部分遵循 ACID 規范：
- 原子性：嚴格遵循
- 一致性：事務完成后的一致性嚴格遵循；事務中的一致性可適當放寬
- 隔離性：并行事務間不可影響；事務中間結果可見性允許安全放寬
- 持久性：嚴格遵循
分布式事務的解決方案
由于分布式事務方案，無法做到完全的ACID的保證，沒有一種完美的方案，能夠解決掉所有業務問題。因此在實際應用中，會根據業務的不同特性，選擇最適合的分布式事務方案。
兩階段提交/XA
XA是由X/Open組織提出的分布式事務的規范，XA規范主要定義了(全局)事務管理器(TM)和(局部)資源管理器(RM)之間的接口。本地的數據庫如mysql在XA中扮演的是RM角色
XA一共分為兩階段：
第一階段（prepare）：即所有的參與者RM準備執行事務并鎖住需要的資源。參與者ready時，向TM報告已準備就緒。
第二階段 (commit/rollback)：當事務管理者(TM)確認所有參與者(RM)都ready后，向所有參與者發送commit命令。
目前主流的數據庫基本都支持XA事務，包括mysql、oracle、sqlserver、postgre
XA 事務由一個或多個資源管理器（RM）、一個事務管理器（TM）和一個應用程序（ApplicationProgram）組成。
這里的RM、TM、AP三個角色是經典的角色劃分，會貫穿后續Saga、Tcc等事務模式。
把上面的轉賬作為例子，一個成功完成的XA事務時序圖如下：
如果有任何一個參與者prepare失敗，那么TM會通知所有完成prepare的參與者進行回滾。
XA事務的特點是：
- 簡單易理解，開發較容易
- 對資源進行了長時間的鎖定，并發度低
如果讀者想要進一步研究XA，go語言以及PHP、Python、Java、C#、Node等都可參考DTM
SAGA
Saga是這一篇數據庫論文sagas提到的一個方案。其核心思想是將長事務拆分為多個本地短事務，由Saga事務協調器協調，如果正常結束那就正常完成，如果某個步驟失敗，則根據相反順序一次調用補償操作。
把上面的轉賬作為例子，一個成功完成的SAGA事務時序圖如下：
Saga一旦到了Cancel階段，那么Cancel在業務邏輯上是不允許失敗了。如果因為網絡或者其他臨時故障，導致沒有返回成功，那么TM會不斷重試，直到Cancel返回成功。
Saga事務的特點：
- 并發度高，不用像XA事務那樣長期鎖定資源
- 需要定義正常操作以及補償操作，開發量比XA大
- 一致性較弱，對于轉賬，可能發生A用戶已扣款，最后轉賬又失敗的情況
論文里面的SAGA內容較多，包括兩種恢復策略，包括分支事務并發執行，我們這里的討論，僅包括最簡單的SAGA
SAGA適用的場景較多，長事務適用，對中間結果不敏感的業務場景適用
如果讀者想要進一步研究SAGA，可參考DTM，里面包括了SAGA成功、失敗回滾的例子，還包括各類網絡異常的處理。
TCC
關于 TCC（Try-Confirm-Cancel）的概念，最早是由 Pat Helland 于 2007 年發表的一篇名為《Life beyond Distributed Transactions:an Apostate’s Opinion》的論文提出。
TCC分為3個階段
- Try 階段：嘗試執行，完成所有業務檢查（一致性）, 預留必須業務資源（準隔離性）
- Confirm 階段：確認執行真正執行業務，不作任何業務檢查，只使用 Try 階段預留的業務資源，Confirm 操作要求具備冪等設計，Confirm 失敗后需要進行重試。
- Cancel 階段：取消執行，釋放 Try 階段預留的業務資源。Cancel 階段的異常和 Confirm 階段異常處理方案基本上一致，要求滿足冪等設計。
把上面的轉賬作為例子，通常會在Try里面凍結金額，但不扣款，Confirm里面扣款，Cancel里面解凍金額，一個成功完成的TCC事務時序圖如下：
TCC的Confirm/Cancel階段在業務邏輯上是不允許返回失敗的，如果因為網絡或者其他臨時故障，導致不能返回成功，TM會不斷的重試，直到Confirm/Cancel返回成功。
TCC特點如下：
- 并發度較高，無長期資源鎖定。
- 開發量較大，需要提供Try/Confirm/Cancel接口。
- 一致性較好，不會發生SAGA已扣款最后又轉賬失敗的情況
- TCC適用于訂單類業務，對中間狀態有約束的業務
如果讀者想要進一步研究TCC，可參考DTM
本地消息表
本地消息表這個方案最初是 ebay 架構師 Dan Pritchett 在 2008 年發表給 ACM 的文章。設計核心是將需要分布式處理的任務通過消息的方式來異步確保執行。
大致流程如下：
寫本地消息和業務操作放在一個事務里，保證了業務和發消息的原子性，要么他們全都成功，要么全都失敗。
容錯機制：
- 扣減余額事務 失敗時，事務直接回滾，無后續步驟
- 輪序生產消息失敗， 增加余額事務失敗都會進行重試
本地消息表的特點：
- 長事務僅需要分拆成多個任務，使用簡單
- 生產者需要額外的創建消息表
- 每個本地消息表都需要進行輪詢
- 消費者的邏輯如果無法通過重試成功，那么還需要
