分布式系統架構中，分布式事務問題是一個繞不過去的挑戰。而微服務架構的流行，讓分布式事問題日益突出！
下面我們以電商購物支付流程中，在各大參與者系統中可能會遇到分布式事務問題的場景進行詳細的分析！
如上圖所示，假設三大參與平台（電商平台、支付平台、銀行）的系統都做了分布式系統架構拆分，按上數中的流程步驟進行分析：
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型事務（或兩階段提交型事務），實時性要求比較高，數據必須可靠。
會計記賬：異步確保型事務（基於可靠消息的最終一致性，可以異步，但數據絕對不能丟，而且一定要記賬成功）
商戶通知：最大努力通知型事務（按規律進行通知，不保證數據一定能通知成功，但會提供可查詢操作接口進行核對）
針對上以分布式事務問題,建議可以參考龍果學院（http://www.roncoo.com）的《微服務架構的分布式事務解決方案》教程中將提供詳細完整的解決方案