作者簡介：煊檍，GitHub ID：sharajava，阿里巴巴中件間 GTS 研發團隊負責人，SEATA 開源項目發起人，曾在 Oracle 北京研發中心多年，從事 WebLogic 核心研發工作。長期專注於中間件，尤其是分佈式事務領域的技術實踐。
Seata 1.2.0 版本重磅發佈新的事務模式：XA 模式，實現對 XA 協議的支持。
這裡，我們從三個方面來深入解讀這個新的特性：
是什麼（What）：XA 模式是什麼？
為什麼（Why）：為什麼支持 XA？
怎麼做（How）：XA 模式是如何實現的，以及怎樣使用？
1. XA 模式是什麼？
這裡有兩個基本的前置概念：
什麼是 XA？
什麼是 Seata 定義的所謂 事務模式？
基於這兩點，再來理解 XA 模式就很自然了。
1.1 什麼是 XA？
XA 規範 是 X/Open 組織定義的分佈式事務處理（DTP，Distributed Transaction Processing）標準。
XA 規範 描述了全局的事務管理器與局部的資源管理器之間的接口。 XA規範 的目的是允許的多個資源（如數據庫，應用服務器，消息隊列等）在同一事務中訪問，這樣可以使 ACID 屬性跨越應用程序而保持有效。
XA 規範 使用兩階段提交（2PC，Two-Phase Commit）來保證所有資源同時提交或回滾任何特定的事務。
XA 規範 在上世紀 90 年代初就被提出。目前，幾乎所有主流的數據庫都對 XA 規範 提供了支持。
1.2 什麼是 Seata 的事務模式？
Seata 定義了全局事務的框架。
全局事務 定義為若干 分支事務 的整體協調：
TM 向 TC 請求發起（Begin）、提交（Commit）、回滾（Rollback）全局事務。
TM 把代表全局事務的 XID 綁定到分支事務上。
RM 向 TC 註冊，把分支事務關聯到 XID 代表的全局事務中。
RM 把分支事務的執行結果上報給 TC。（可選）
TC 發送分支提交（Branch Commit）或分支回滾（Branch Rollback）命令給 RM。
Seata 的 全局事務 處理過程，分為兩個階段：
執行階段 ：執行 分支事務，並 保證 執行結果滿足是 可回滾的（Rollbackable）和持久化的（Durable）。
完成階段： 根據 執行階段 結果形成的決議，應用通過 TM 發出的全局提交或回滾的請求給 TC，TC 命令 RM 驅動 分支事務 進行 Commit 或 Rollback。
Seata 的所謂 事務模式 是指：運行在 Seata 全局事務框架下的 分支事務 的行為模式。準確地講，應該叫作 分支事務模式。
不同的 事務模式 區別在於 分支事務 使用不同的方式達到全局事務兩個階段的目標。即，回答以下兩個問題：
執行階段 ：如何執行並 保證 執行結果滿足是 可回滾的（Rollbackable）和持久化的（Durable）。
完成階段： 收到 TC 的命令後，如何做到分支的提交或回滾？
以我們 Seata 的 AT 模式和 TCC 模式為例來理解：
AT 模式
執行階段：
可回滾：根據 SQL 解析結果，記錄回滾日誌
持久化：回滾日誌和業務 SQL 在同一個本地事務中提交到數據庫
完成階段：
分支提交：異步刪除回滾日誌記錄
分支回滾：依據回滾日誌進行反向補償更新
TCC 模式
執行階段：
調用業務定義的 Try 方法（完全由業務層面保證 可回滾和持久化）
完成階段：
分支提交：調用各事務分支定義的 Confirm 方法
分支回滾：調用各事務分支定義的 Cancel 方法
1.3 什麼是 Seata 的 XA 模式？
XA 模式：
在 Seata 定義的分佈式事務框架內，利用事務資源（數據庫、消息服務等）對 XA 協議的支持，以 XA 協議的機制來管理分支事務的一種 事務模式。
執行階段：
可回滾：業務 SQL 操作放在 XA 分支中進行，由資源對 XA 協議的支持來保證 可回滾
持久化：XA 分支完成後，執行 XA prepare，同樣，由資源對 XA 協議的支持來保證 持久化（即，之後任何意外都不會造成無法回滾的情況）
完成階段：
分支提交：執行 XA 分支的 commit
分支回滾：執行 XA 分支的 rollback
2. 為什麼支持 XA？
為什麼要在 Seata 中增加 XA 模式呢？支持 XA 的意義在哪裡呢？
2.1 補償型事務模式的問題
本質上，Seata 已經支持的 3 大事務模式：AT、TCC、Saga 都是 補償型 的。
補償型 事務處理機制構建在 事務資源 之上（要麼在中間件層面，要麼在應用層面），事務資源 本身對分佈式事務是無感知的。
事務資源 對分佈式事務的無感知存在一個根本性的問題：無法做到真正的 全局一致性 。
比如，一條庫存記錄，處在 補償型 事務處理過程中，由 100 扣減為 50。此時，倉庫管理員連接數據庫，查詢統計庫存，就看到當前的 50。之後，事務因為異外回滾，庫存會被補償回滾為 100。顯然，倉庫管理員查詢統計到的 50 就是 髒 數據。
可以看到，補償型 分佈式事務機制因為不要求 事務資源 本身（如數據庫）的機制參與，所以無法保證從事務框架之外的全局視角的數據一致性。
2.2 XA 的價值
與 補償型 不同，XA 協議 要求 事務資源 本身提供對規範和協議的支持。
因為 事務資源 感知並參與分佈式事務處理過程，所以 事務資源（如數據庫）可以保障從任意視角對數據的訪問有效隔離，滿足全局數據一致性。
比如，上一節提到的庫存更新場景，XA 事務處理過程中，中間態數據庫存 50 由數據庫本身保證，是不會倉庫管理員的查詢統計 看到的。（當然隔離級別需要 讀已提交 以上）
除了 全局一致性 這個根本性的價值外，支持 XA 還有如下幾個方面的好處：
業務無侵入：和 AT 一樣，XA 模式將是業務無侵入的，不給應用設計和開發帶來額外負擔。
數據庫的支持廣泛：XA 協議被主流關係型數據庫廣泛支持，不需要額外的適配即可使用。
多語言支持容易：因為不涉及 SQL 解析，XA 模式對 Seata 的 RM 的要求比較少，為不同語言開發 SDK 較之 AT 模式將更 薄，更容易。
傳統基於 XA 應用的遷移：傳統的，基於 XA 協議的應用，遷移到 Seata 平臺，使用 XA 模式將更平滑。
2.3 XA 廣泛被質疑的問題
不存在某一種分佈式事務機制可以完美適應所有場景，滿足所有需求。
XA 規範早在上世紀 90 年代初就被提出，用以解決分佈式事務處理這個領域的問題。
現在，無論 AT 模式、TCC 模式還是 Saga 模式，這些模式的提出，本質上都源自 XA 規範對某些場景需求的無法滿足。
XA 規範定義的分佈式事務處理機制存在一些被廣泛質疑的問題，針對這些問題，我們是如何思考的呢？
1. 數據鎖定：數據在整個事務處理過程結束前，都被鎖定，讀寫都按隔離級別的定義約束起來。
思考：
數據鎖定是獲得更高隔離性和全局一致性所要付出的代價。
補償型 的事務處理機制，在 執行階段 即完成分支（本地）事務的提交，（資源層面）不鎖定數據。而這是以犧牲 隔離性 為代價的。
另外，AT 模式使用 全局鎖保障基本的寫隔離，實際上也是鎖定數據的，只不過鎖在 TC 側集中管理，解鎖效率高且沒有阻塞的問題。
2. 協議阻塞：XA prepare 後，分支事務進入阻塞階段，收到 XA commit 或 XA rollback 前必須阻塞等待。
思考：
協議的阻塞機制本身並不是問題，關鍵問題在於 協議阻塞 遇上 數據鎖定。
如果一個參與全局事務的資源 “失聯” 了（收不到分支事務結束的命令），那麼它鎖定的數據，將一直被鎖定。進而，甚至可能因此產生死鎖。
這是 XA 協議的核心痛點，也是 Seata 引入 XA 模式要重點解決的問題。
基本思路是兩個方面：避免 “失聯” 和 增加 “自解鎖” 機制。（這裡涉及非常多技術細節，暫時不展開，在後續 XA 模式演進過程中，會專門拿出來討論）
3. 性能差：性能的損耗主要來自兩個方面：一方面，事務協調過程，增加單個事務的 RT；另一方面，併發事務數據的鎖衝突，降低吞吐。
思考：
和不使用分佈式事務支持的運行場景比較，性能肯定是下降的，這點毫無疑問。
本質上，事務（無論是本地事務還是分佈式事務）機制就是拿部分 性能的犧牲 ，換來 編程模型的簡單 。
與同為 業務無侵入 的 AT 模式比較：
首先，因為同樣運行在 Seata 定義的分佈式事務框架下，XA 模式並沒有產生更多事務協調的通信開銷。
其次，併發事務間，如果數據存在熱點，產生鎖衝突，這種情況，在 AT 模式（默認使用全局鎖）下同樣存在的。
所以，在影響性能的兩個主要方面，XA 模式並不比 AT 模式有非常明顯的劣勢。
AT 模式性能優勢主要在於：集中管理全局數據鎖，鎖的釋放不需要 RM 參與，釋放鎖非常快；另外，全局提交的事務，完成階段 異步化。
3. XA 模式如何實現以及怎樣用？
3.1 XA 模式的設計
3.1.1 設計目標
XA 模式的基本設計目標，兩個主要方面：
從 場景 上，滿足 全局一致性 的需求。
從 應用上，保持與 AT 模式一致的無侵入。
從 機制 上，適應分佈式微服務架構的特點。
整體思路：
與 AT 模式相同的：以應用程序中 本地事務 的粒度，構建到 XA 模式的 分支事務。
通過數據源代理，在應用程序本地事務範圍外，在框架層面包裝 XA 協議的交互機制，把 XA 編程模型 透明化。
把 XA 的 2PC 拆開，在分支事務 執行階段 的末尾就進行 XA prepare，把 XA 協議完美融合到 Seata 的事務框架，減少一輪 RPC 交互。
3.1.2 核心設計
1. 整體運行機制
XA 模式 運行在 Seata 定義的事務框架內：
執行階段（E xecute）：
XA start/XA end/XA prepare + SQL + 註冊分支
完成階段（F inish）：
XA commit/XA rollback
2. 數據源代理
XA 模式需要 XAConnection。
獲取 XAConnection 兩種方式：
方式一：要求開發者配置 XADataSource
方式二：根據開發者的普通 DataSource 來創建
第一種方式，給開發者增加了認知負擔，需要為 XA 模式專門去學習和使用 XA 數據源，與 透明化 XA 編程模型的設計目標相違背。
第二種方式，對開發者比較友好，和 AT 模式使用一樣，開發者完全不必關心 XA 層面的任何問題，保持本地編程模型即可。
我們優先設計實現第二種方式：數據源代理根據普通數據源中獲取的普通 JDBC 連接創建出相應的 XAConnection。
類比 AT 模式的數據源代理機制，如下：
但是，第二種方法有侷限：無法保證兼容的正確性。
實際上，這種方法是在做數據庫驅動程序要做的事情。不同的廠商、不同版本的數據庫驅動實現機制是廠商私有的，我們只能保證在充分測試過的驅動程序上是正確的，開發者使用的驅動程序版本差異很可能造成機制的失效。
這點在 Oracle 上體現非常明顯。參見 Druid issue：
https://github.com/alibaba/druid/issues/3707
綜合考慮，XA 模式的數據源代理設計需要同時支持第一種方式：基於 XA 數據源進行代理。
類比 AT 模式的數據源代理機制，如下：
3. 分支註冊
XA start 需要 Xid 參數。
這個 Xid 需要和 Seata 全局事務的 XID 和 BranchId 關聯起來，以便由 TC 驅動 XA 分支的提交或回滾。
目前 Seata 的 BranchId 是在分支註冊過程，由 TC 統一生成的，所以 XA 模式分支註冊的時機需要在 XA start 之前。
將來一個可能的優化方向：
把分支註冊儘量延後。類似 AT 模式在本地事務提交之前才註冊分支，避免分支執行失敗情況下，沒有意義的分支註冊。
這個優化方向需要 BranchId 生成機制的變化來配合。BranchId 不通過分支註冊過程生成，而是生成後再帶著 BranchId 去註冊分支。
4. 小結
這裡只通過幾個重要的核心設計，說明 XA 模式的基本工作機制。
此外，還有包括 連接保持、異常處理等重要方面，有興趣可以從項目代碼中進一步瞭解。
以後會陸續寫出來和大家交流。
3.1.3 演進規劃
XA 模式總體的演進規劃如下：
第 1 步（已經完成）：首個版本（1.2.0），把 XA 模式原型機制跑通。確保只增加，不修改，不給其他模式引入的新問題。
第 2 步（計劃 5 月完成）：與 AT 模式必要的融合、重構。
第 3 步（計劃 7 月完成）：完善異常處理機制，進行上生產所必需的打磨。
第 4 步（計劃 8 月完成）：性能優化。
第 5 步（計劃 2020 年內完成）：結合 Seata 項目正在進行的面向雲原生的 Transaction Mesh 設計，打造雲原生能力。
3.2 XA 模式的使用
從編程模型上，XA 模式與 AT 模式保持完全一致。
可以參考 Seata 官網的樣例：seata-xa
樣例場景是 Seata 經典的，涉及庫存、訂單、賬戶 3 個微服務的商品訂購業務。
在樣例中，上層編程模型與 AT 模式完全相同。只需要修改數據源代理，即可實現 XA 模式與 AT 模式之間的切換。
<code> @Bean("dataSourceProxy")
public DataSource dataSource(DruidDataSource druidDataSource) {
// DataSourceProxy for AT mode
// return new DataSourceProxy(druidDataSource);
// DataSourceProxyXA for XA mode
return new DataSourceProxyXA(druidDataSource);
}/<code>4. 總結
在當前的技術發展階段，不存一個分佈式事務處理機制可以完美滿足所有場景的需求。
一致性、可靠性、易用性、性能等諸多方面的系統設計約束，需要用不同的事務處理機制去滿足。
Seata 項目最核心的價值在於：構建一個全面解決分佈式事務問題的 標準化 平臺。
基於 Seata，上層應用架構可以根據實際場景的需求，靈活選擇合適的分佈式事務解決方案。
XA 模式的加入，補齊了 Seata 在 全局一致性 場景下的缺口，形成 AT、TCC、Saga、XA 四大 事務模式 的版圖，基本可以滿足所有場景的分佈式事務處理訴求。
當然 XA 模式和 Seata 項目本身都還不盡完美，有很多需要改進和完善的地方。非常歡迎大家參與到項目的建設中，共同打造一個標準化的分佈式事務平臺。
打造高效交付團隊心得
HTTP3能給應用帶來什麼好處？這裡有一份最新評測數據
如何處理代碼中的魔術數字(Magic Number)
mini-redis，一個精簡版Redis實現，基於Rust開發
當不懂某項技術時候，如何面試工程師？
理想的DevOps流程怎麼做？看看Slack的代碼部署實
技術原創及架構實踐文章，歡迎通過公眾號菜單「聯繫我們」進行投稿。
高可用架構
改變互聯網的構建方式
