分布式事務，原理簡單，寫起來全是坑！
今天我們就一起來看下另一種模式，XA 模式！
其實我覺得 seata 中的四種不同的分布式事務模式，學完 AT、TCC 以及 XA 就夠了，Saga 不好玩，而且長事務本身就有很多問題，也不推薦使用。
Seata 中的 XA 模式實際上是基于 MySQL 的 XA 兩階段提交發展出來的，所以學習 XA 模式，需要小伙伴們先理解 MySQL 中的 XA 是怎么一回事，把 MySQL 中的 XA 搞清楚了，再來學習 Seata 中的 XA 模式就容易的多了。
1. 什么是 XA 規范
1.1 什么是兩階段提交
我們先來稍微回顧一下兩階段提交。
先來看下面一張圖：
這張圖里涉及到三個概念：
- AP：這個不用多說，AP 就是應用程序本身。
- RM：RM 是資源管理器，也就是事務的參與者，大部分情況下就是指數據庫，一個分布式事務往往涉及到多個 RM。
- TM：TM 就是事務管理器，創建分布式事務并協調分布式事務中的各個子事務的執行和狀態，子事務就是指在 RM 上執行的具體操作。
那么什么是兩階段(Two-Phase Commit, 簡稱 2PC)提交？
兩階段提交說白了道理很簡單，松哥舉個簡單例子來和大家說明兩階段提交：
比如下面一張圖：
我們在 Business 中分別調用 Storage 與 Order、Account，這三個中的操作要同時成功或者同時失敗，但是由于這三個分處于不同服務，因此我們只能先讓這三個服務中的操作各自執行，三個服務中的事務各自執行就是兩階段中的第一階段。
第一階段執行完畢后，先不要急著提交，因為三個服務中有的可能執行失敗了，此時需要三個服務各自把自己一階段的執行結果報告給一個事務協調者（也就是前面文章中的 Seata Server），事務協調者收到消息后，如果三個服務的一階段都執行成功了，此時就通知三個事務分別提交，如果三個服務中有服務執行失敗了，此時就通知三個事務分別回滾。
這就是所謂的兩階段提交。
總結一下：兩階段提交中，事務分為參與者（例如上圖的各個具體服務）與協調者（上文案例中的 Seata Server），參與者將操作成敗通知協調者，再由協調者根據所有參與者的反饋情報決定各參與者是要提交操作還是中止操作，這里的參與者可以理解為 RM，協調者可以理解為 TM。
不過 Seata 中的各個分布式事務模式，基本都是在二階段提交的基礎上演化出來的，因此并不完全一樣，這點需要小伙伴們注意。
1.2 什么是 XA 規范
XA 規范 是 X/Open 組織定義的分布式事務處理（DTP，Distributed Transaction Processing）標準。
XA 規范描述了全局的事務管理器與局部的資源管理器之間的接口。XA規范的目的是允許多個資源（如數據庫，應用服務器，消息隊列等）在同一事務中訪問，這樣可以使 ACID 屬性跨越應用程序而保持有效。
XA 規范使用兩階段提交來保證所有資源同時提交或回滾任何特定的事務。
XA 規范在上世紀 90 年代初就被提出。目前，幾乎所有主流的數據庫都對 XA 規范提供了支持。
XA 事務的基礎是兩階段提交協議。需要有一個事務協調者來保證所有的事務參與者都完成了準備工作(第一階段)。如果協調者收到所有參與者都準備好的消息，就會通知所有的事務都可以提交了（第二階段）。MySQL 在這個 XA 事務中扮演的是參與者的角色，而不是協調者(事務管理器)。
MySQL 的 XA 事務分為內部 XA 和外部 XA。外部 XA 可以參與到外部的分布式事務中，需要應用層介入作為協調者；內部 XA 事務用于同一實例下跨多引擎事務，由 Binlog 作為協調者，比如在一個存儲引擎提交時，需要將提交信息寫入二進制日志，這就是一個分布式內部 XA 事務，只不過二進制日志的參與者是 MySQL 本身。MySQL 在 XA 事務中扮演的是一個參與者的角色，而不是協調者。
2. MySQL 中的 XA
接下來松哥通過一個簡單的例子先給大家看下 MySQL 中的 XA 是怎么玩的。
2.1 兩階段事務提交
比如說轉賬操作，我用 MySQL 中的 XA 事務來和大家演示一下從一個賬戶中轉出 10 塊錢：
上面這段事務提交是一個兩階段事務提交的案例。
具體執行步驟如下：
- XA START "transfer_money"：這個表示開啟一個 XA 事務，后面的字符串是事務的 xid，這是一個唯一字符串，開啟之后，事務的狀態變為ACTIVE。
- update account set amount=amount-10 where account_no='A'; 這個表示執行具體的 SQL。
- XA END "transfer_money"：這個表示結束一個 XA 事務，此時事務的狀態轉為IDLE。
- XA PREPARE "transfer_money"：這個將事務置為 PREPARE 狀態。
- XA COMMIT "transfer_money"：這個用來提交事務，提交之后，事務的狀態就是 COMMITED。
最后一步，可以通過 XA COMMIT 來提交，也可以通過 XA ROLLBACK 來回滾，回滾后事務的狀態就是 ROLLBACK。
另外第四步可以省略，即一個 IDLE 狀態的 XA 事務可以直接提交或者回滾。
我們來看下面一張流程圖：
從這張圖里我們可以看出，事務可以一步提交，也可以兩階段提交，都是支持的。如果是兩階段提交，prepare 之后，其實是在等其他的資源管理器（RM）反饋結果。
2.2 事務直接提交
松哥再給大家演示一下事務一步提交：
這個就比較簡單，沒啥好說的。
這塊再跟大家介紹另外一個 XA 事務相關的命令 XA RECOVER，如下圖：
XA RECOVER 可以列出所有處于 PREPARE 狀態的 XA 事務，其他狀態的事務則都不會列出來，如上圖。
2.3 事務回滾
再舉一個事務回滾的例子：
小伙伴們看到，xa recover 可以查看處于 prepare 狀態的事務，事務回滾有三個參數：第一個參數，是以 gtrid_length 為依據，從 data 字符串上截取下來的值；第二個參數，是第一個從 data 上截取下來值之后，data 剩余的值，在本案例中，第一次被截取之后，就不剩了，所以第二個參數是一個空字符串；第三個參數是 formatID 的值。
回滾之后，再執行 xa recover 就看不到東西了。
2.4 小結
在用一個客戶端環境下，XA 事務和本地(非 XA )事務互相排斥，如果已經通過 XA START 來開啟一個事務，則本地事務不會被啟動，直到 XA 事務被提交或者被回滾為止。
相反的，如果已經使用 START TRANSACTION 啟動一個本地事務，則 XA 語句不能被使用，直到該事務被提交或者回滾為止，而且 XA 事務僅僅被 InnoDB 存儲引擎支持。
3. Seata 中的 XA
3.1 Seata 中的 XA 模式
我們先來看一點理論知識，3.3 小節我們再來看代碼實踐。
通過上面的介紹，大家已經知道了 MySQL 中的 XA 事務是怎么回事了，Seata 中的 XA 模式其實就是在 MySQL 中 XA 模式的基礎上實現的。Seata 中的 XA 模式就是在 Seata 定義的分布式事務框架內，利用事務資源（數據庫、消息服務等）對 XA 協議的支持，以 XA 協議的機制來管理分支事務的一種事務模式。
我們來看下面一張圖：
我來大概說一下這個執行步驟：
- 首先由 TM 開啟全局分布式事務。
- 各個業務 SQL 分別放在不同的 XA 分支中進行，具體執行的流程就是XA Start->業務 SQL->XA End，這個流程跟我 2.1 小節和大家演示的 MySQL 中 XA 事務的流程是一致的。
- 分支中的 XA 事務執行完成后，執行XA prepare，并將自己執行的狀態報告給 TC。
- 其他的分支事務均按照 2、3 步驟來執行。
- 當所有分支事務都執行完畢后，TC 也收到了各個分支事務報告上來的執行狀態，如果所有狀態都 OK，則 TC 通知所有 RM 執行XA Commit 完成事務的最終提交，否則 TC 通知所有 RM 執行XA Rollback 進行事務回滾。
這就是 Seata 中的 XA 模式！只要小伙伴們理解了 2.2 小節中 MySQL 的 XA 模式，那么 Seata 中的 XA 模式就很好理解了。
3.2 特色
前面小伙伴們已經學會了 AT 和 TCC 兩種不同的分布式事務模式了，現在再加入一個 XA，我們再來把這三個放在一起比較下。
- AT 和 TCC 都是通過反向補償將數據復原的，也就是說，通過一條更新語句將數據復原；XA 因為是 MySQL 自己的功能，所以不是反向補償，而是正兒八經的回滾（處于 prepare 狀態的數據并沒有 commit，將來在二階段可以選擇 commit 或者 rollback）。
- AT 和 XA 模式是無侵入的分布式事務解決方案，適用于不希望對業務進行改造的場景，幾乎0學習成本；TCC 則有一定的代碼侵入。
- AT 和 XA 都是一種全自動的，無論是提交呀，回滾呀（無論是真回滾還是反向補償），都是全自動的，就是開發者基本上不需要額外做什么事情；TCC 則是一種手動的分布式事務，一階段的 prepare、二階段的 commit 或者 rollback，所有邏輯都是開發者自己寫的。
- 松哥發前面文章的時候，有小伙伴提到分布式事務的一致性問題，XA 模式是分布式強一致性的解決方案，但是因為性能低而導致使用較少。
好啦，比較完啦，那就上代碼吧！
3.3 代碼實踐
小伙伴們只需要搞明白前面的 AT 模式后，XA 模式其實跟 AT 模式差不多！就是替換一下數據源即可！話是這么說，不過真做起來，還是有很多坑，我們一起來看下。
為了方便大家理解，本文我就不重新搞案例了，咱們還用上篇文章那個下訂單的案例來演示。
這是一個商品下單的案例，一共有五個服務，我來和大家稍微解釋下：
eureka：這是服務注冊中心。
account：這是賬戶服務，可以查詢/修改用戶的賬戶信息（主要是賬戶余額）。
order：這是訂單服務，可以下訂單。
storage：這是一個倉儲服務，可以查詢/修改商品的庫存數量。
bussiness：這是業務，用戶下單操作將在這里完成。
這個案例講了一個什么事呢？
當用戶想要下單的時候，調用了 bussiness 中的接口，bussiness 中的接口又調用了它自己的 service，在 service 中，首先開啟了全局分布式事務，然后通過 feign 調用 storage 中的接口去扣庫存，然后再通過 feign 調用 order 中的接口去創建訂單（order 在創建訂單的時候，不僅會創建訂單，還會扣除用戶賬戶的余額），在這個過程中，如果有任何一個環節出錯了（余額不足、庫存不足等導致的問題），就會觸發整體的事務回滾。
本案例具體架構如下圖：
這個案例就是一個典型的分布式事務問題，storage、order 以及 account 中的事務分屬于不同的微服務，但是我們希望他們同時成功或者同時失敗。
這個案例的基本架構我這里就不重復搭建了，小伙伴們可以參考上篇文章，這里我們主要來看 XA 事務如何添加進來。
3.3.1 數據庫配置
由于 XA 模式利用的是 MySQL 自身對 XA 規范的實現，所以 XA 機制實際上是不需要 undo_log 表的，小伙伴們可以把你 AT 模式中的 undo_log 表刪除啦～ 如果刪除后運行 Java 程序報錯，那說明你的 XA 模式使用的不地道！注意看松哥后面的講解哦。
接下來我就來說幾個要點。
數據庫驅動
這是一個坑。松哥經過反復測試，seata 中的 XA 模式和最新版的 MySQL 驅動不兼容，運行時候會有錯誤，經過測試，MySQL 8.0.11 這個版本的驅動是沒問題的，所以在 account、storage 以及 order 三個需要數據庫調用的服務上，記得修改一下數據庫驅動依賴的版本號：
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<scope>runtime</scope>
<version>8.0.11</version>
</dependency>
druid 依賴
有的小伙伴們看到這里用到了阿里的 Druid 數據庫連接池，就趕緊加入這個依賴！殊不知，這又掉入版本兼容的坑了，spring-cloud-starter-alibaba-seata 依賴中實際上包含了 druid 依賴，而且版本號是沒有問題的！所以小伙伴們千萬別自己手動加 druid 依賴，可能會因為版本號問題掉坑。
關掉數據源代碼
接下來就是關閉掉 seata 數據源代理了，account、storage 以及 order 里邊都改一下，加入如下配置：
seata.enable-auto-data-source-proxy=false
配置自定義數據源
接下來就是配置自定義數據源了，account、order 以及 storage 都要配置，如下：
@Configuration
public class DataSourceConfiguration {
@Bean
@ConfigurationProperties(prefix = "spring.datasource")
public DruidDataSource druidDataSource() {
return new DruidDataSource();
}
@Bean("dataSourceProxy")
@Primary
public DataSource dataSource(DruidDataSource druidDataSource) {
return new DataSourceProxyXA(druidDataSource);
}
@Bean
public SqlSessionFactory sqlSessionFactory(DataSource dataSourceProxy)throws Exception{
SqlSessionFactoryBean sqlSessionFactoryBean = new SqlSessionFactoryBean();
sqlSessionFactoryBean.setDataSource(dataSourceProxy);
sqlSessionFactoryBean.setTransactionFactory(new SpringManagedTransactionFactory());
return sqlSessionFactoryBean.getObject();
}
}
先配置 DruidDataSource，但這不是我們最終目的，最終目的是配置 DataSourceProxyXA，看名字就知道，這就會把事務切換為 XA 模式，最后，還需要基于 DataSourceProxyXA 來配置一下 MyBatis，都是常規操作，不多說。
