兩階段提交（2PC）

?????????XA是X/Open CAE Specification (Distributed Transaction Processing)模型中定義的TM（Transaction Manager）與RM（Resource Manager）之間進行通信的接口。

?? ?????在XA規范中，數據庫充當RM角色，應用需要充當TM的角色，即生成全局的txId，調用XAResource接口，把多個本地事務協調為全局統一的分布式事務。

????????二階段提交是XA的標準實現。它將分布式事務的提交拆分為2個階段：prepare和commit/rollback。

????????2PC模型中，在prepare階段需要等待所有參與子事務的反饋，因此可能造成數據庫資源鎖定時間過長，不適合并發高以及子事務生命周長較長的業務場景。兩階段提交這種解決方案屬于犧牲了一部分可用性來換取的一致性。

補償事務（TCC）

TCC 其實就是采用的補償機制，其核心思想是：針對每個操作，都要注冊一個與其對應的確認和補償（撤銷）操作。TCC模型是把鎖的粒度完全交給業務處理。它分為三個階段：

Try 階段主要是對業務系統做檢測及資源預留

Confirm 階段主要是對業務系統做確認提交，Try階段執行成功并開始執行 Confirm階段時，默認 Confirm階段是不會出錯的。即：只要Try成功，Confirm一定成功。

Cancel 階段主要是在業務執行錯誤，需要回滾的狀態下執行的業務取消，預留資源釋放。

匯款服務和收款服務分別需要實現，Try-Confirm-Cancel接口，并在業務初始化階段將其注入到TCC事務管理器中。、

由此可以看出，TCC模型對業務的侵入強，改造的難度大。

本地消息表（異步確保）

本地消息表這種實現方式應該是業界使用最多的，其核心思想是將分布式事務拆分成本地事務進行處理，這種思路是來源于ebay。我們可以從下面的流程圖中看出其中的一些細節：

基本思路就是：

????????消息生產方，需要額外建一個消息表，并記錄消息發送狀態。消息表和業務數據要在一個事務里提交，也就是說他們要在一個數據庫里面。然后消息會經過MQ發送到消息的消費方。如果消息發送失敗，會進行重試發送。

????????消息消費方，需要處理這個消息，并完成自己的業務邏輯。此時如果本地事務處理成功，表明已經處理成功了，如果處理失敗，那么就會重試執行。如果是業務上面的失敗，可以給生產方發送一個業務補償消息，通知生產方進行回滾等操作。

????????生產方和消費方定時掃描本地消息表，把還沒處理完成的消息或者失敗的消息再發送一遍。如果有靠譜的自動對賬補賬邏輯，這種方案還是非常實用的。

盡最大努力通知

? ??????最大努力通知方案主要也是借助MQ消息系統來進行事務控制，這一點與可靠消息最終一致方案一樣。看來MQ中間件確實在一個分布式系統架構中，扮演者重要的角色。最大努力通知方案是比較簡單的分布式事務方案，它本質上就是通過定期校對，實現數據一致性。

最大努力通知方案的實現

業務活動的主動方，在完成業務處理之后，向業務活動的被動方發送消息，允許消息丟失。

主動方可以設置時間階梯型通知規則，在通知失敗后按規則重復通知，直到通知N次后不再通知。

主動方提供校對查詢接口給被動方按需校對查詢，用于恢復丟失的業務消息。

業務活動的被動方如果正常接收了數據，就正常返回響應，并結束事務。

如果被動方沒有正常接收，根據定時策略，向業務活動主動方查詢，恢復丟失的業務消息

最大努力通知方案的特點

1、用到的服務模式：可查詢操作、冪等操作。

2、被動方的處理結果不影響主動方的處理結果；

3、適用于對業務最終一致性的時間敏感度低的系統；

4、適合跨企業的系統間的操作，或者企業內部比較獨立的系統間的操作，比如銀行通知、商戶通知等；

案例：

eBay 本地消息表

本地消息表這種實現方式的思路，其實是源于ebay，后來通過支付寶等公司的布道，在業內廣泛使用。其基本的設計思想是將遠程分布式事務拆分成一系列的本地事務。如果不考慮性能及設計優雅，借助關系型數據庫中的表即可實現。

舉個經典的跨行轉賬的例子來描述。第一步，扣款1W，通過本地事務保證了憑證消息插入到消息表中。第二步，通知對方銀行賬戶上加1W了。那問題來了，如何通知到對方呢？

通常采用兩種方式：

采用時效性高的MQ，由對方訂閱消息并監聽，有消息時自動觸發事件

采用定時輪詢掃描的方式，去檢查消息表的數據。

類似使用本地消息表+消息通知的還有去哪兒，蘑菇街

各種第三方支付回調

最大努力通知型。如支付寶、微信的支付回調接口方式，不斷回調直至成功，或直至調用次數衰減至失敗狀態。

我們可以怎么來做

2PC/3PC需要資源管理器(mysql, redis)支持XA協議，且整個事務的執行期間需要鎖住事務資源，會降低性能。故先排除。

TCC的模式，需要事務接口提供try,confirm,cancel三個接口，提高了編程的復雜性。需要依賴于業務方來配合提供這樣的接口。推行難度大，暫時排除。

最大努力通知型，應用于異構或者服務平臺當中

可以看到ebay的經典模式中，分布式的事務，是通過本地事務+可靠消息，來達到事務的最終一致性的。但是出現了事務消息，就把本地事務的工作給涵蓋在事務消息當中了。所以，接下來要基于事務消息來套我們的應用場景，看起是否滿足我們對分布式事務產品的要求。