分布式事務解決方案
花開堪折直須折，莫待無花空折枝。
一、簡述
分布式事務是指事務的操作位於不同的節點上，需要保證事務的ACID特性。在分布式架構下，每個節點只知曉自身操作的成功與失敗，無法知悉其他節點的操作狀態。當一個事務跨多個節點時，為了保持事務的原子性與一致性，從而引入一個協調者來統一管控所有參與者的操作結果，並指引它們最終是否把操作結果進行診治的提交(commit)和回滾(rollback)。例如在購物下單場景中，庫存和訂單如果不在同一個節點上，就涉及分布式事務。
二、解決方案
在分布式系統中要實現分布式事務，常見的解決方案有兩段提交(2PC)、三段提交(3PC)、事務補償(TCC)、本地消息表(異步確保)、MQ事務方案(可靠消息事務)、最大努力通知和Saga事務。
1、兩階段提交（2PC）
二階段提交協議（Two-phase Commit，即 2PC）是常用的分布式事務解決方案，即將事務的提交過程分為准備階段和提交階段兩個階段來進行處理，通過引入協調者（Coordinator）來協調參與者的行為，並最終決定這些參與者是否要真正執行事務。
- 事務協調者（事務管理器）：事務的發起者
- 事務參與者（資源管理器）：事務的執行者
准備階段（投票階段）
協調者詢問參與者事務是否執行成功，參與者發回事務執行結果，但該階段並未提交事務。
- 協調者向所有參與者發送事務內容，詢問是否可以提交事務，並等待答復；
- 各參與者執行事務操作，將 undo 和 redo 信息記入事務日志中（但不提交事務）；
- 如參與者執行成功，給協調者反饋同意，否則反饋終止。
提交階段（執行階段）
如果事務在每個參與者上都執行成功，事務協調者發送通知讓參與者提交事務；否則，協調者發送通知讓參與者回滾事務。
在准備階段，參與者執行了事務，但是還未提交。只有在提交階段接收到協調者發來的通知后，才進行提交或者回滾。
- 事務協調者節點向所有參與者節點發出正式提交(
commit)的請求； - 參與者節點正式完成操作，並釋放在整個事務期間內占用的資源；
- 參與者節點向協調者節點發送ACK完成消息；
- 事務協調者節點收到所有參與者節點反饋的ACK完成消息后，完成事務。
2PC優缺
優點
- 盡量保證了數據的強一致，適合對數據強一致要求很高的關鍵領域。（其實也不能100%保證強一致，如宕機）
缺點
- 性能問題：執行過程中，所有參與節點都是事務阻塞型的。當參與者占有公共資源時，其他第三方節點訪問公共資源不得不處於阻塞狀態。
- 可靠性問題：參與者發生故障。協調者需要給每個參與者額外指定超時機制，超時后整個事務失敗。協調者發生故障。參與者會一直阻塞下去。需要額外的備機進行容錯。
- 數據一致性問題：二階段無法解決的問題如協調者在發出
commit消息之后宕機，而唯一接收到這條消息的參與者同時也宕機了。那么即使協調者通過選舉協議產生了新的協調者，這條事務的狀態也是不確定的，沒人知道事務是否被已經提交。 - 實現復雜：犧牲了可用性，對性能影響較大，不適合高並發高性能場景。
2、三階段提交（3PC）
三階段提交協議是二階段提交協議的改進版本，其有兩個改動點。
- 在協調者和參與者中都引入超時機制；
- 在第一階段和第二階段中插入一個准備階段，保證了在最后提交階段之前各參與節點的狀態是一致的。
即除了引入超時機制之外，3PC把2PC的准備階段再次一分為二，這樣三階段提交就有CanCommit、PreCommit和DoCommit三個階段。
3PC優缺點
優點
相比二階段提交，三階段提交降低了阻塞范圍，在等待超時后協調者或參與者會中斷事務。避免了協調者單點問題，階段 3 中協調者出現問題時，參與者會繼續提交事務。
缺點
數據不一致問題依然存在，當在參與者收到 preCommit 請求后等待 doCommit 指令時，此時如果協調者請求中斷事務，而協調者無法與參與者正常通信，會導致參與者繼續提交事務，造成數據不一致。
3、事務補償（TCC）
TCC（Try Confirm Cancel）方案是一種應用層面侵入業務的兩階段提交，是目前最火的一種柔性事務方案。TCC采用了補償機制，其核心思想就是針對每個操作，都要注冊一個與其對應的確認和補償（撤銷）操作。它分為Try、Confirm和Cancel三個階段。
-
Try 階段主要是對業務系統做檢測及資源預留；
-
Confirm 階段主要是對業務系統做確認提交，Try階段執行成功並開始執行 Confirm階段時，默認 Confirm階段是不會出錯的，即：只要Try成功，Confirm一定成功；
-
Cancel 階段主要是在業務執行錯誤，需要回滾的狀態下執行的業務取消，預留資源釋放。
轉賬例子：假入 Bob 要向 Smith 轉賬，思路大概是： 我們有一個本地方法，里面依次調用。
- 首先在 Try 階段，要先調用遠程接口把 Smith 和 Bob 的錢給凍結起來；
- 在 Confirm 階段，執行遠程調用的轉賬的操作，轉賬成功進行解凍。
- 如果第2步執行成功，那么轉賬成功，如果第二步執行失敗，則調用遠程凍結接口對應的解凍方法 (Cancel)。
TCC優缺點
優點
跟2PC比起來，實現以及流程相對簡單了一些，但數據的一致性比2PC差。
缺點
在2和3步中都有可能會失敗。TCC屬於應用層的一種補償方式，所以需要程序員在實現的時候多寫很多補償的代碼，在一些場景中，一些業務流程可能用TCC不太好定義及處理。
4、本地消息表（異步確保）
本地消息表方案的核心思路是將分布式事務拆分成本地事務進行處理。通過在事務主動發起方額外新建事務消息表，事務發起方處理業務和記錄事務消息在本地事務中完成，輪詢事務消息表的數據發送事務消息，事務被動方基於消息中間件消費事務消息表中的事務。
上圖中整體的處理步驟如下：
- 事務主動方在同一個本地事務中處理業務和寫消息表操作；
- 事務主動方通過消息中間件，通知事務被動方處理事務通知事務待消息。消息中間件可以基於 Kafka、RocketMQ 消息隊列，事務主動方主動寫消息到消息隊列，事務消費方消費並處理消息隊列中的消息；
- 事務被動方通過消息中間件，通知事務主動方事務已處理的消息；
- 事務主動方接收中間件的消息，更新消息表的狀態為已處理。
本地消息表優缺點
優點
避免了分布式事務，實現了最終一致性。
缺點
消息表會耦合到業務系統中，如果沒有封裝好的解決方案，會有很多雜活需要處理。
5、MQ事務方案(可靠消息事務)
MQ事務方案是對本地消息表的封裝，將本地消息表基於 MQ 內部，其他方面的協議基本與本地消息表一致。
6、最大努力通知
最大努力通知方案是對MQ事務方案的進一步優化。它在事務主動方增加了消息校對的接口，如果事務被動方沒有接收到消息，此時可以調用事務主動方提供的消息校對的接口主動獲取。
其適用於業務通知類型，例如微信交易的結果，就是通過最大努力通知方式通知各個商戶，既有回調通知，也有交易查詢接口。
7、Saga事務
Saga 事務核心思想是將長事務拆分為多個本地短事務，由 Saga 事務協調器協調，如果正常結束那就正常完成，如果某個步驟失敗，則根據相反順序一次調用補償操作。
Saga 事務基本協議如下：
- 每個 Saga 事務由一系列冪等的有序子事務(sub-transaction) Ti 組成。
- 每個 Ti 都有對應的冪等補償動作 Ci，補償動作用於撤銷 Ti 造成的結果。
Saga 的執行順序有兩種：
- T1, T2, T3, ..., Tn
- T1, T2, ..., Tj, Cj,..., C2, C1，其中0 < j < n
TCC事務補償機制有一個預留(Try)動作，相當於先報存一個草稿，然后才提交；而Saga事務沒有預留動作，直接提交。對於事務異常，Saga提供了向后恢復和向前恢復兩種恢復策略。
向后恢復（backward recovery）
backward recovery，即上面提到的第二種執行順序，其中j是發生錯誤的sub-transaction，這種做法的效果是撤銷掉之前所有成功的sub-transation，使得整個Saga的執行結果撤銷。
向前恢復（forward recovery）
forward recovery，即適用於必須要成功的場景，執行順序是類似於這樣的：T1, T2, ..., Tj(失敗), Tj(重試),..., Tn，其中j是發生錯誤的sub-transaction。該情況下不需要Ci。
三、總結
各分布式事務方案的常見使用場景：
- 2PC/3PC：依賴於數據庫，能夠很好的提供強一致性和強事務性，但相對來說延遲比較高，比較適合傳統的單體應用，在同一個方法中存在跨庫操作的情況，不適合高並發和高性能要求的場景。
- TCC：適用於執行時間確定且較短，實時性要求高，對數據一致性要求高，比如互聯網金融企業最核心的三個服務：交易、支付、賬務。
- 本地消息表/MQ 事務：都適用於事務中參與方支持操作冪等，對一致性要求不高，業務上能容忍數據不一致到一個人工檢查周期，事務涉及的參與方、參與環節較少，業務上有對賬/校驗系統兜底。
- Saga 事務：由於 Saga 事務不能保證隔離性，需要在業務層控制並發，適合於業務場景事務並發操作同一資源較少的情況。Saga 相比缺少預提交動作，導致補償動作的實現比較麻煩，例如業務是發送短信，補償動作則得再發送一次短信說明撤銷，用戶體驗比較差。Saga 事務較適用於補償動作容易處理的場景。
四、Seta
上述幾種方案都是分布式事務的理論知識，Seta是分布式解放方案的一個落地實現。
Seata 是一款開源的分布式事務解決方案，致力於提供高性能和簡單易用的分布式事務服務。Seata 將為用戶提供了 AT、TCC、SAGA 和 XA 事務模式，為用戶打造一站式的分布式解決方案。
- 對業務無侵入：即減少技術架構上的微服務化所帶來的分布式事務問題對業務的侵入；
- 高性能：減少分布式事務解決方案所帶來的性能消耗。
- Seta官方文檔：https://seata.io/zh-cn/index.html
花開堪折直須折
莫待無花空折枝