分布式系統架構中，分布式事務問題是一個繞不過去的挑戰。而微服務架構的流行，讓分布式事問題日益突出！
下面我們以電商購物支付流程中，在各大參與者系統中可能會遇到分布式事務問題的場景進行詳細的分析！
如上圖所示，假設三大參與平台（電商平台、支付平台、銀行）的系統都做了分布式系統架構拆分，按上數中的流程步驟進行分析：
1、電商平台中建立訂單：預留庫存、預扣減積分、鎖定優惠券，此時電商平台内各服務間會有分布式事務問題，因為此時已經要跨多個内部服務修改資料；
2、支付平台中建立支付訂單（選銀行卡支付）：查詢賬戶、查詢限制規則，符合條件的就建立支付訂單并跳轉銀行，此時不會有分布式事務問題，因為還不會跨服務改資料；
3、銀行平台中建立交易訂單：查找賬戶、建立交易記錄、判斷賬戶餘額并扣款、增加積分、通知支付平台，此時也會有分布式事務問題（如果是服務化架構的話）；
4、支付平台收到銀行扣款結果：更改訂單狀态、給賬戶加款、給積分帳戶增加積分、生成會計分錄、通知電商平台等，此時也會有分布式事務問題；
5、電商平台收到支付平台的支付結果：更改訂單狀态、扣減庫存、扣減積分、使用優惠券、增加消費積分等，系統内部各服務間調用也會遇到分布式事問題；
如上圖，支付平台收到銀行扣款結果後的内部處理流程：
1、支付平台的支付網關對銀行通知結果進行校驗，然後調用支付訂單服務執行支付訂單處理；
2、支付訂單服務根據銀行扣款結果更改支付訂單狀态；
3、調用資金賬戶服務給電商平台的商戶賬戶加款（實際過程中可能還會有各種的成本計費；如果是餘額支付，還可能是同時從使用者賬戶扣款，給商戶賬戶加款）；
4、調用積分服務給使用者積分賬戶增加積分；
5、調用會計服務向會計（财務）系統寫進交易原始憑證生成會計分錄；
6、調用通知服務将支付處理結果通知電商平台；
如上圖，把支付系統中的銀行扣款成功回調處理流程提取出來，對應的分布式事務問題的代碼場景：
/ 支付訂單處理 /
@transactional(rollbackfor = exception.class)
public void completeorder() {
orderdao.update(); // 訂單服務本地更新訂單狀态
accountservice.update(); // 調用資金賬戶服務給資金帳戶加款
pointservice.update(); // 調用積分服務給積分帳戶增加積分
accountingservice.insert(); // 調用會計服務向會計系統寫入會計原始憑證
merchantnotifyservice.notify(); // 調用商戶通知服務向商戶發送支付結果通知
}
本地事務控制還可行嗎？
以上分布式事務問題，需要多種分布式事務解決方案來進行處理。
訂單處理：本地事務
資金賬戶加款、積分賬戶增加積分：tcc型事務（或兩階段送出型事務），實時性要求比較高，資料必須可靠。
會計記賬：異步確定型事務（基于可靠消息的最終一緻性，可以異步，但資料絕對不能丢，而且一定要記賬成功）
商戶通知：最大努力通知型事務（按規律進行通知，不保證資料一定能通知成功，但會提供可查詢操作接口進行核對）
龍果支付系統（開源版）
face/2at3stmqiktepfpe6frdec3trbetw6ny.jpg