https://seata.io/zh-cn/docs/user/mode/xa
https://seata.io/zh-cn/docs/dev/mode/xa-mode
XA 規範 是 X/Open 組織定義的分佈式事務處理（DTP，Distributed Transaction Processing）標準，XA 規範 描述了全局的TM與局部的RM之間的接口，幾乎所有主流的數據庫都對 XA 規範 提供了支持。
XA 模式是從 1.2 版本支持的事務模式。XA 規範 是 X/Open 組織定義的分佈式事務處理（DTP，Distributed Transaction Processing）標準。Seata XA 模式是利用事務資源（數據庫、消息服務等）對 XA 協議的支持，以 XA 協議的機制來管理分支事務的一種事務模式。
前提
- 基於支持本地 ACID 事務的關係型數據庫。
- Java 應用，通過 JDBC 訪問數據庫。
兩階段提交
XA是規範，目前主流數據庫都實現了這種規範，實現的原理都是基於兩階段提交。
正常情況：
異常情況：
一階段：
- 事務協調者通知每個事物參與者執行本地事務
- 本地事務執行完成後報告事務執行狀態給事務協調者，此時事務不提交，繼續持有數據庫鎖
二階段：
- 事務協調者基於一階段的報告來判斷下一步操作
- 如果一階段都成功，則通知所有事務參與者，提交事務
- 如果一階段任意一個參與者失敗，則通知所有事務參與者回滾事務
4.1.2.Seata的XA模型
Seata對原始的XA模式做了簡單的封裝和改造，以適應自己的事務模型，基本架構如圖：
RM一階段的工作：
① 註冊分支事務到TC
② 執行分支業務sql但不提交
③ 報告執行狀態到TC
TC二階段的工作：
-
TC檢測各分支事務執行狀態
a.如果都成功，通知所有RM提交事務
b.如果有失敗，通知所有RM回滾事務
RM二階段的工作：
- 接收TC指令，提交或回滾事務
優缺點
XA模式的優點是什麼？
- 事務的強一致性，滿足ACID原則。
- 常用數據庫都支持，實現簡單，並且沒有代碼侵入
XA模式的缺點是什麼？
- 因爲一階段需要鎖定數據庫資源，等待二階段結束才釋放，性能較差
- 依賴關係型數據庫實現事務
實現XA模式
Seata的starter已經完成了XA模式的自動裝配，實現非常簡單，步驟如下：
1）修改application.yml文件（每個參與事務的微服務），開啓XA模式：
seata:
enabled: true
tx-service-group: default_tx_group # 事務組名稱
service:
vgroup-mapping:
default_tx_group: default
grouplist:
default: 127.0.0.1:8091
data-source-proxy-mode: XA
2）給發起全局事務的入口方法添加@GlobalTransactional註解:
本例中是OrderServiceImpl中的create方法.
四種模式對比
我們從以下幾個方面來對比四種實現：
- 一致性：能否保證事務的一致性？強一致還是最終一致？
- 隔離性：事務之間的隔離性如何？
- 代碼侵入：是否需要對業務代碼改造？
- 性能：有無性能損耗？
- 場景：常見的業務場景
如圖：
