今天我們就一起來看下另一種模式，XA 模式！

其實我覺得 seata 中的四種不同的分布式事務模式，學完 AT、TCC 以及 XA 就夠了，Saga 不好玩，而且長事務本身就有很多問題，也不推薦使用。

Seata 中的 XA 模式實際上是基于 MySQL 的 XA 兩階段提交發(fā)展出來的，所以學習 XA 模式，需要小伙伴們先理解 MySQL 中的 XA 是怎么一回事，把 MySQL 中的 XA 搞清楚了，再來學習 Seata 中的 XA 模式就容易的多了。

1. 什么是 XA 規(guī)范

1.1 什么是兩階段提交

我們先來稍微回顧一下兩階段提交。

先來看下面一張圖：

這張圖里涉及到三個概念：

• AP：這個不用多說，AP 就是應用程序本身。
• RM：RM 是資源管理器，也就是事務的參與者，大部分情況下就是指數(shù)據(jù)庫，一個分布式事務往往涉及到多個 RM。
• TM：TM 就是事務管理器，創(chuàng)建分布式事務并協(xié)調分布式事務中的各個子事務的執(zhí)行和狀態(tài)，子事務就是指在 RM 上執(zhí)行的具體操作。

那么什么是兩階段(Two-Phase Commit, 簡稱 2PC)提交？

兩階段提交說白了道理很簡單，松哥舉個簡單例子來和大家說明兩階段提交：

比如下面一張圖：

我們在 Business 中分別調用 Storage 與 Order、Account，這三個中的操作要同時成功或者同時失敗，但是由于這三個分處于不同服務，因此我們只能先讓這三個服務中的操作各自執(zhí)行，三個服務中的事務各自執(zhí)行就是兩階段中的第一階段。

第一階段執(zhí)行完畢后，先不要急著提交，因為三個服務中有的可能執(zhí)行失敗了，此時需要三個服務各自把自己一階段的執(zhí)行結果報告給一個事務協(xié)調者（也就是前面文章中的 Seata Server），事務協(xié)調者收到消息后，如果三個服務的一階段都執(zhí)行成功了，此時就通知三個事務分別提交，如果三個服務中有服務執(zhí)行失敗了，此時就通知三個事務分別回滾。

這就是所謂的兩階段提交。

總結一下：兩階段提交中，事務分為參與者（例如上圖的各個具體服務）與協(xié)調者（上文案例中的 Seata Server），參與者將操作成敗通知協(xié)調者，再由協(xié)調者根據(jù)所有參與者的反饋情報決定各參與者是要提交操作還是中止操作，這里的參與者可以理解為 RM，協(xié)調者可以理解為 TM。

不過 Seata 中的各個分布式事務模式，基本都是在二階段提交的基礎上演化出來的，因此并不完全一樣，這點需要小伙伴們注意。

1.2 什么是 XA 規(guī)范

XA 規(guī)范 是 X/Open 組織定義的分布式事務處理（DTP，Distributed Transaction Processing）標準。

XA 規(guī)范描述了全局的事務管理器與局部的資源管理器之間的接口。XA規(guī)范的目的是允許多個資源（如數(shù)據(jù)庫，應用服務器，消息隊列等）在同一事務中訪問，這樣可以使 ACID 屬性跨越應用程序而保持有效。

XA 規(guī)范使用兩階段提交來保證所有資源同時提交或回滾任何特定的事務。

XA 規(guī)范在上世紀 90 年代初就被提出。目前，幾乎所有主流的數(shù)據(jù)庫都對 XA 規(guī)范提供了支持。

XA 事務的基礎是兩階段提交協(xié)議。需要有一個事務協(xié)調者來保證所有的事務參與者都完成了準備工作(第一階段)。如果協(xié)調者收到所有參與者都準備好的消息，就會通知所有的事務都可以提交了（第二階段）。MySQL 在這個 XA 事務中扮演的是參與者的角色，而不是協(xié)調者(事務管理器)。

MySQL 的 XA 事務分為內部 XA 和外部 XA。外部 XA 可以參與到外部的分布式事務中，需要應用層介入作為協(xié)調者；內部 XA 事務用于同一實例下跨多引擎事務，由 Binlog 作為協(xié)調者，比如在一個存儲引擎提交時，需要將提交信息寫入二進制日志，這就是一個分布式內部 XA 事務，只不過二進制日志的參與者是 MySQL 本身。MySQL 在 XA 事務中扮演的是一個參與者的角色，而不是協(xié)調者。

2. MySQL 中的 XA

接下來松哥通過一個簡單的例子先給大家看下 MySQL 中的 XA 是怎么玩的。

2.1 兩階段事務提交

比如說轉賬操作，我用 MySQL 中的 XA 事務來和大家演示一下從一個賬戶中轉出 10 塊錢：

上面這段事務提交是一個兩階段事務提交的案例。

具體執(zhí)行步驟如下：

最后一步，可以通過 XA COMMIT 來提交，也可以通過 XA ROLLBACK 來回滾，回滾后事務的狀態(tài)就是 ROLLBACK。

另外第四步可以省略，即一個 IDLE 狀態(tài)的 XA 事務可以直接提交或者回滾。

我們來看下面一張流程圖：

從這張圖里我們可以看出，事務可以一步提交，也可以兩階段提交，都是支持的。如果是兩階段提交，prepare 之后，其實是在等其他的資源管理器（RM）反饋結果。

2.2 事務直接提交

松哥再給大家演示一下事務一步提交：

這個就比較簡單，沒啥好說的。

這塊再跟大家介紹另外一個 XA 事務相關的命令 XA RECOVER，如下圖：

XA RECOVER 可以列出所有處于 PREPARE 狀態(tài)的 XA 事務，其他狀態(tài)的事務則都不會列出來，如上圖。

2.3 事務回滾

再舉一個事務回滾的例子：

小伙伴們看到，xa recover 可以查看處于 prepare 狀態(tài)的事務，事務回滾有三個參數(shù)：第一個參數(shù)，是以 gtrid_length 為依據(jù)，從 data 字符串上截取下來的值；第二個參數(shù)，是第一個從 data 上截取下來值之后，data 剩余的值，在本案例中，第一次被截取之后，就不剩了，所以第二個參數(shù)是一個空字符串；第三個參數(shù)是 formatID 的值。

回滾之后，再執(zhí)行 xa recover 就看不到東西了。

2.4 小結

在用一個客戶端環(huán)境下，XA 事務和本地(非 XA )事務互相排斥，如果已經(jīng)通過 XA START 來開啟一個事務，則本地事務不會被啟動，直到 XA 事務被提交或者被回滾為止。

相反的，如果已經(jīng)使用 START TRANSACTION 啟動一個本地事務，則 XA 語句不能被使用，直到該事務被提交或者回滾為止，而且 XA 事務僅僅被 InnoDB 存儲引擎支持。

3. Seata 中的 XA

3.1 Seata 中的 XA 模式

我們先來看一點理論知識，3.3 小節(jié)我們再來看代碼實踐。

通過上面的介紹，大家已經(jīng)知道了 MySQL 中的 XA 事務是怎么回事了，Seata 中的 XA 模式其實就是在 MySQL 中 XA 模式的基礎上實現(xiàn)的。Seata 中的 XA 模式就是在 Seata 定義的分布式事務框架內，利用事務資源（數(shù)據(jù)庫、消息服務等）對 XA 協(xié)議的支持，以 XA 協(xié)議的機制來管理分支事務的一種事務模式。

我們來看下面一張圖：

我來大概說一下這個執(zhí)行步驟：

這就是 Seata 中的 XA 模式！只要小伙伴們理解了 2.2 小節(jié)中 MySQL 的 XA 模式，那么 Seata 中的 XA 模式就很好理解了。

3.2 特色

前面小伙伴們已經(jīng)學會了 AT 和 TCC 兩種不同的分布式事務模式了，現(xiàn)在再加入一個 XA，我們再來把這三個放在一起比較下。

好啦，比較完啦，那就上代碼吧！

3.3 代碼實踐

小伙伴們只需要搞明白前面的 AT 模式后，XA 模式其實跟 AT 模式差不多！就是替換一下數(shù)據(jù)源即可！話是這么說，不過真做起來，還是有很多坑，我們一起來看下。

為了方便大家理解，本文我就不重新搞案例了，咱們還用上篇文章那個下訂單的案例來演示。

這是一個商品下單的案例，一共有五個服務，我來和大家稍微解釋下：

• eureka：這是服務注冊中心。
• account：這是賬戶服務，可以查詢/修改用戶的賬戶信息（主要是賬戶余額）。
• order：這是訂單服務，可以下訂單。
• storage：這是一個倉儲服務，可以查詢/修改商品的庫存數(shù)量。
• bussiness：這是業(yè)務，用戶下單操作將在這里完成。

這個案例講了一個什么事呢？

當用戶想要下單的時候，調用了 bussiness 中的接口，bussiness 中的接口又調用了它自己的 service，在 service 中，首先開啟了全局分布式事務，然后通過 feign 調用 storage 中的接口去扣庫存，然后再通過 feign 調用 order 中的接口去創(chuàng)建訂單（order 在創(chuàng)建訂單的時候，不僅會創(chuàng)建訂單，還會扣除用戶賬戶的余額），在這個過程中，如果有任何一個環(huán)節(jié)出錯了（余額不足、庫存不足等導致的問題），就會觸發(fā)整體的事務回滾。

本案例具體架構如下圖：

這個案例就是一個典型的分布式事務問題，storage、order 以及 account 中的事務分屬于不同的微服務，但是我們希望他們同時成功或者同時失敗。

這個案例的基本架構我這里就不重復搭建了，小伙伴們可以參考上篇文章，這里我們主要來看 XA 事務如何添加進來。

3.3.1 數(shù)據(jù)庫配置

由于 XA 模式利用的是 MySQL 自身對 XA 規(guī)范的實現(xiàn)，所以 XA 機制實際上是不需要 undo_log 表的，小伙伴們可以把你 AT 模式中的 undo_log 表刪除啦 如果刪除后運行 Java 程序報錯，那說明你的 XA 模式使用的不地道！注意看松哥后面的講解哦。

接下來我就來說幾個要點。

這是一個坑。松哥經(jīng)過反復測試，seata 中的 XA 模式和最新版的 MySQL 驅動不兼容，運行時候會有錯誤，經(jīng)過測試，MySQL 8.0.11 這個版本的驅動是沒問題的，所以在 account、storage 以及 order 三個需要數(shù)據(jù)庫調用的服務上，記得修改一下數(shù)據(jù)庫驅動依賴的版本號：

mysql mysql-connector-java runtime 8.0.11

有的小伙伴們看到這里用到了阿里的 Druid 數(shù)據(jù)庫連接池，就趕緊加入這個依賴！殊不知，這又掉入版本兼容的坑了，spring-cloud-starter-alibaba-seata 依賴中實際上包含了 druid 依賴，而且版本號是沒有問題的！所以小伙伴們千萬別自己手動加 druid 依賴，可能會因為版本號問題掉坑。

接下來就是關閉掉 seata 數(shù)據(jù)源代理了，account、storage 以及 order 里邊都改一下，加入如下配置：

seata.enable-auto-data-source-proxy=false

接下來就是配置自定義數(shù)據(jù)源了，account、order 以及 storage 都要配置，如下：

@Configurationpublic 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，都是常規(guī)操作，不多說。

好啦，就這樣，我們的 seata XA 模式就配置好啦 其他的代碼都和 AT 模式一樣，不再贅述。

原文鏈接：https://mp.weixin.qq.com/s/29PmqK_bzDgh8bl9SBY3Uw