提起分布式系統，就會涉及分布式事務，本文就以金融項目的轉賬業務為例，分析各種業務場景下的轉賬業務的事物問題。
一、業務場景
以工商銀行轉賬業務為例，那么項目的分布式架構大致如下，一個銀行的一個支行部署一個節點，那么相同節點之間的業務就是本地事務、不同節點之間的就是分布式事務
轉賬業務包括以下三種情況
支行內轉賬：同為工行的相同支行內轉賬（本地事務）
行內轉賬：同為工行的非同支行內轉賬 （分布式事務）
跨行轉賬：和其他銀行的系統進行轉賬 （分布式事務）
1.1、支行內轉賬業務
如用戶A和用戶B都是工行-杭州支行的用戶，A向B轉賬10000元，那么就需要保證事務，從而達到A的賬戶-10000，而B的賬戶+10000的效果
由於是本地事務，所以A賬戶的扣減和B賬戶的增加就可以放在一個事務中實現，基本上沒有太大的問題，不管哪一步異常了都可以實現事務回滾。
1.2、行內轉賬
如用戶A是杭州支行，用戶B是北京支行，A向B轉賬10000元，那么雖然都是工行用戶，但是是分布式部署的，就會涉及到跨庫的分布式事務問題，一般解決方案有同步和異步兩種方式：
同步方式可以如下：
1、創建轉賬訂單，訂單狀態為待成功
2、用戶A扣減10000元
3、發起轉賬請求到北京支行
4、北京支行創建轉賬訂單，訂單狀態為待成功
5、用戶B增加10000元
6、北京支行訂單狀態改為成功並返回結果
7、杭州支行接收響應結果，如果為成功則提交事務表示轉賬成功，如果為失敗則更新訂單狀態為轉賬失敗
8、定時任務根據查詢轉賬失敗訂單在北京支行的訂單訂單狀態，如果失敗，則回滾轉賬事務；如果成功則提交事務
異步方式如下：
1、創建轉賬訂單
2、用戶A凍結10000元
3、提交事務
4、異步發起轉賬請求，判斷結果
結果可以為：
1、轉賬成功：確認成功
2、轉賬失敗：確認失敗
3、請求異常：結果不確認
對於結果不確定的情況就采用：查詢的方式查詢結果，查詢結果還是不確定的話
就采用定時任務查詢異常訂單查詢
1.3、跨行轉賬
如用戶A是工行用戶，用戶B是建行用戶，A向B轉賬10000元，這里兩個用戶不是同一個行的用戶，基本上就不會再采用同步的方式進行轉賬了。
異步方式如下：
1、創建轉賬訂單，訂單狀態為待成功
2、用戶A凍結10000元
3、提交事務
這里需要保證的是用戶資金和訂單狀態的事務
異步發送http請求到其他行進行轉賬業務，
結果可以為：
1、轉賬成功：確認成功
2、轉賬失敗：確認失敗
3、請求異常：結果不確認
對於結果不確定的情況就采用：查詢的方式查詢結果，查詢結果還是不確定的話
就采用定時任務查詢異常訂單查詢
金融項目一般不會太重視轉賬的實時性，而是重視轉賬的一致性，比較涉及到的是金錢，所以必須要確保轉賬的事務性。
總體來說，解決轉賬的分布式事務還是以異步為主，采用的是最終一致性來解決分布式事務問題。大致流程如下：
1、事務1執行事務，並創建訂單，確保訂單和金額變得的一致性
2、異步發起轉賬請求
3、接收異步回調或同步響應
4、如果是成功則更新訂單狀態和金額、如果是失敗則回滾、如果是不確定則通過查詢的方式來確認訂單的結果
5、根據訂單的最終結果來更新數據
二、其他分布式事務解決方案
2.1、基於XA的二階段提交協議
基於二階段提交的方案主要是將事務分成了兩個階段，一個是事務准備階段，一個是事務提交階段，並且需要一個事務管理者的角色，也就是事務管理器
第一階段：
1、事務管理器通知所有參與事務的各個本地資源管理器，通知他們准備事務
2、各個本地資源管理器進行事務准備，寫好事務日志並執行事務，但是不提交，然后將本地事務執行的結果上報給事務管理器
第二階段：
1、事務管理器接收各個本地資源管理器執行的事務結果，如果全部成功則表示事務成功，需要提交；如果有一個失敗則表示事務失敗，需要回滾
2、事務管理器向各個資源管理器發生提交或回滾請求，各個資源管理器分別進行提交或回滾（提交或回滾的耗時很短，失敗的概率相對很低）
2.2、TCC方案
TCC方案是將事務分成了三個階段，分別是try、commit、callback階段。
事務開始時，業務應用會向事務協調器注冊啟動事務。之后業務應用會調用所有服務的try接口，完成一階段准備。之后事務協調器會根據try接口返回情況，決定調用confirm接口或者cancel接口。如果接口調用失敗，會進行重試。
TCC方案讓應用自己定義數據庫操作的粒度，使得降低鎖沖突、提高吞吐量成為可能。 當然TCC方案也有不足之處，集中表現在以下兩個方面：
- 對應用的侵入性強。業務邏輯的每個分支都需要實現try、confirm、cancel三個操作，應用侵入性較強，改造成本高。
- 實現難度較大。需要按照網絡狀態、系統故障等不同的失敗原因實現不同的回滾策略。為了滿足一致性的要求，confirm和cancel接口必須實現冪等。
上述原因導致TCC方案大多被研發實力較強、有迫切需求的大公司所采用。微服務倡導服務的輕量化、易部署，而TCC方案中很多事務的處理邏輯需要應用自己編碼實現，復雜且開發量大。
2.3、基於MQ的最終一致性
基於MQ的一致性相當於是異步實現的分布式事務，將事務分成了兩個不關聯的本地事務，基於MQ進行同步，根據最終結果實現一致性從而達到分布式事務
2.4、基於fescar實現的分布式事務
XA的第一階段是執行sql，但是不提交，第二階段一起提交 （會導致鎖的時間是整個事務的時間）
Fescar的第一階段是各個分支事務執行並提交事務，只是在提交之前持久化了回滾日志（undo log），第二階段如果是提交的話就只需要刪除持久化日志即可；否則才需要執行回滾操作
主要是對XA的優化，第一階段的區別