XA是一個分散式事務協議，由Tuxedo提出。XA中大致分為兩部分：事務管理器和本地資源管理器。其中本地資源管理器往往由資料庫實現，比如Oracle、DB2這些商業資料庫都實現了XA介面，而事務管理器作為全域性的排程者，負責各個本地資源的提交和回滾。XA實現分散式事務的原理如下：

總的來說，XA協議比較簡單，而且一旦商業資料庫實現了XA協議，使用分散式事務的成本也比較低。但是，XA也有致命的缺點，那就是效能不理想，特別是在交易下單鏈路，往往併發量很高，XA無法滿足高併發場景。XA目前在商業資料庫支援的比較理想，在mysql資料庫中支援的不太理想，mysql的XA實現，沒有記錄prepare階段日誌，主備切換回導致主庫與備庫資料不一致。許多nosql也沒有支援XA，這讓XA的應用場景變得非常狹隘。

2:非XA方式

使用XA方式的效率低,使用訊息佇列消除分散式事務又太過複雜,基於效率和時間成本的考慮,我們選用spring的鏈式事務管理器也就是非XA方式 ChainedTransactionManager.他最大努力一階段提交模式中,一個粗糙的事務管理器實現僅僅將一系列其他的事務管理器連結在一起,去實現事務的同步,倘若業務處理成功,所有的事務將會提交,否則他們會回滾,最大努力一次提交模式的安全性不如XA事務但是也是相當不錯的,因為能夠承受風險獲得較高的吞吐量收益,如果我們將關鍵業務處理服務設計為一個幕等式(idempotent),這樣發生錯誤的可能性也很小.

3:用訊息佇列消除分散式事務

所謂的訊息事務就是基於訊息中介軟體的兩階段提交，本質上是對訊息中介軟體的一種特殊利用，它是將本地事務和發訊息放在了一個分散式事務裡，保證要麼本地操作成功成功並且對外發訊息成功，要麼兩者都失敗，開源的RocketMQ就支援這一特性，具體原理如下：

1、A系統向訊息中介軟體傳送一條預備訊息2、訊息中介軟體儲存預備訊息並返回成功3、A執行本地事務4、A傳送提交訊息給訊息中介軟體

透過以上4步完成了一個訊息事務。對於以上的4個步驟，每個步驟都可能產生錯誤，下面一一分析：

步驟一出錯，則整個事務失敗，不會執行A的本地操作步驟二出錯，則整個事務失敗，不會執行A的本地操作步驟三出錯，這時候需要回滾預備訊息，怎麼回滾？答案是A系統實現一個訊息中介軟體的回撥介面，訊息中介軟體會去不斷執行回撥介面，檢查A事務執行是否執行成功，如果失敗則回滾預備訊息步驟四出錯，這時候A的本地事務是成功的，那麼訊息中介軟體要回滾A嗎？答案是不需要，其實透過回撥介面，訊息中介軟體能夠檢查到A執行成功了，這時候其實不需要A發提交訊息了，訊息中介軟體可以自己對訊息進行提交，從而完成整個訊息事務

基於訊息中介軟體的兩階段提交往往用在高併發場景下，將一個分散式事務拆成一個訊息事務（A系統的本地操作+發訊息）+B系統的本地操作，其中B系統的操作由訊息驅動，只要訊息事務成功，那麼A操作一定成功，訊息也一定發出來了，這時候B會收到訊息去執行本地操作，如果本地操作失敗，訊息會重投，直到B操作成功，這樣就變相地實現了A與B的分散式事務。原理如下：

雖然上面的方案能夠完成A和B的操作，但是A和B並不是嚴格一致的，而是最終一致的，我們在這裡犧牲了一致性，換來了效能的大幅度提升。當然，這種玩法也是有風險的，如果B一直執行不成功，那麼一致性會被破壞，具體要不要玩，還是得看業務能夠承擔多少風險