分佈式系統架構中，分佈式事務問題是一個繞不過去的挑戰。而微服務架構的流行，讓分佈式事問題日益突出！
下面我們以電商購物支付流程中，在各大參與者系統中可能會遇到分佈式事務問題的場景進行詳細的分析！
如上圖所示，假設三大參與平臺（電商平臺、支付平臺、銀行）的系統都做了分佈式系統架構拆分，按上數中的流程步驟進行分析：
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）的《微服務架構的分佈式事務解決方案》視頻教程中將提供詳細完整的方案供大家學習和應用。
http://www.roncoo.com/details?cid=7ae3d7eddc4742f78b0548aa8bd9ccdb
