分散式系統架構中，分散式事務問題是一個繞不過去的挑戰。而微服務架構的流行，讓分散式事問題日益突出！

下面我們以電商購物支付流程中，在各大參與者系統中可能會遇到分散式事務問題的場景進行詳細的分析！

如上圖所示，假設三大參與平臺（電商平臺、支付平臺、銀行）的系統都做了分散式系統架構拆分，按上數中的流程步驟進行分析：

1、電商平臺中建立訂單：預留庫存、預扣減積分、鎖定優惠券，此時電商平臺內各服務間會有分散式事務問題，因為此時已經要跨多個內部服務修改資料；

2、支付平臺中建立支付訂單（選銀行卡支付）：查詢賬戶、查詢限制規則，符合條件的就建立支付訂單並跳轉銀行，此時不會有分散式事務問題，因為還不會跨服務改資料；

3、銀行平臺中建立交易訂單：查詢賬戶、建立交易記錄、判斷賬戶餘額並扣款、增加積分、通知支付平臺，此時也會有分散式事務問題（如果是服務化架構的話）；

4、支付平臺收到銀行扣款結果：更改訂單狀態、給賬戶加款、給積分帳戶增加積分、生成會計分錄、通知電商平臺等，此時也會有分散式事務問題；

5、電商平臺收到支付平臺的支付結果：更改訂單狀態、扣減庫存、扣減積分、使用優惠券、增加消費積分等，系統內部各服務間呼叫也會遇到分散式事問題；

如上圖，支付平臺收到銀行扣款結果後的內部處理流程：

1、支付平臺的支付閘道器對銀行通知結果進行校驗，然後呼叫支付訂單服務執行支付訂單處理；

2、支付訂單服務根據銀行扣款結果更改支付訂單狀態；

3、呼叫資金賬戶服務給電商平臺的商戶賬戶加款（實際過程中可能還會有各種的成本計費；如果是餘額支付，還可能是同時從使用者賬戶扣款，給商戶賬戶加款）；

4、呼叫積分服務給使用者積分賬戶增加積分；

5、呼叫會計服務向會計（財務）系統寫進交易原始憑證生成會計分錄；

6、呼叫通知服務將支付處理結果通知電商平臺；

如上圖，把支付系統中的銀行扣款成功回撥處理流程提取出來，對應的分散式事務問題的程式碼場景：

/** 支付訂單處理 **/

@Transactional(rollbackFor = Exception.class)

public void completeOrder() {

orderDao

accountService.update();  // 呼叫資金賬戶服務給資金帳戶加款

pointService.update();  // 呼叫積分服務給積分帳戶增加積分

accountingService.insert();  // 呼叫會計服務向會計系統寫入會計原始憑證

merchantNotifyService.notify();  // 呼叫商戶通知服務向商戶傳送支付結果通知

}

本地事務控制還可行嗎？

以上分散式事務問題，需要多種分散式事務解決方案來進行處理。

訂單處理：本地事務

資金賬戶加款、積分賬戶增加積分：TCC型事務（或兩階段提交型事務），實時性要求比較高，資料必須可靠。

會計記賬：非同步確保型事務（基於可靠訊息的最終一致性，可以非同步，但資料絕對不能丟，而且一定要記賬成功）

商戶通知：最大努力通知型事務（按規律進行通知，不保證資料一定能通知成功，但會提供可查詢操作介面進行核對）