Seata 強一致性事務模式 XA 的設計理念

XA規範是什麼?

• 是分佈式事務處理 DTP（Distributed Transaction Processing）的標準。

• 是描述全局的事務管理器和局部的資源管理器之間的接口規範。

• 允許多個資源（如數據庫、應用服務、消息隊列）在同一個事務中訪問，使 ACID 屬性跨應用程序而保持有序。

• 本質上可以理解爲 2PC，使用了 2PC 協議來保證所有的資源同時提交或回滾特定事務。

• 數據庫本身支持本地事務 ACID，XA 讓 ACID 庫外應用。

DTP模式定義的幾個角色？

• AP 應用程序

• RM 資源管理器，事務的參與者，具體的一個一個的微服務對應的數據源。

• TM 事務管理器，管理整個事務生命週期並協調各個 RM。

• AP 應用程序，比如訂單服務、庫存服務。

• RM 資源管理器，可以理解爲一個數據庫 mysql，應用程序通過 JDBC 連接，AP 通過 RM 對資源進行控制，資源必須實現 XA 定義的接口。

• TM 事務管理器，負責分配事務唯一標識，監控事務執行進度，並負責事務的提交或回滾。

TM 一般是內嵌到應用程序當中，比如 AP 持有訂單庫和商品庫 2 個數據源，應用程序通過 TM 通知訂單庫和商品庫來創建訂單和扣減庫存，具體的 2 個 RM 此時是未提交事務，把數據鎖住了，還沒有提交，所以此時的商品和訂單資源是鎖定狀態。

實際上 RM 代理了之前的數據庫提交操作，RM 告訴 TM 我準備好了。

2 個 RM 都發送給 TM 說我準備好了，TM 收到了所有的 RM 的通知，TM 才發送下一個指令，通知所有 RM 進行真正的提交，然後釋放資源，即 2 個 RM 分別把鎖釋放掉。

其實這個模式就是 2PC，AT 模式有一個記錄日誌的 undolog，記錄着之前的數據，XA 模式沒有 undolog。

XA模式的核心

如果一個參與全局事務的 RM 資源失聯了，收不到分支事務的結束命令，那它鎖定的數據就會被一直鎖定，就有可能會產生死鎖，這是 XA 協議要解決的核心問題，也是 Seata 引入 XA 模式要解決的問題。

XA 規範的本質就是 2PC，利用數據庫本身的 CRUD 來進行代理。

Seata事務模式的原型

DTP 模式包含 AP、RM、TM。

Seata XA 模式包含 TC 事務協調者，TM 事務管理器，RM 資源管理器，TC 是 Seata 自己定義的。

Seata 定義了全局的事務框架，全局事務可以定義爲若干個分支事務的整體協調。

TM 開啓全局事務，負責全局的提交或回滾請求給 TC，TM 會創建全局事務的 xid。

TM如何把分支的事務定義在一個全局事務中的？

給整個全局事務中具體的分支事務規定一個統一的 id，比如當前這個 RM 事務參與者的 xid 爲 1，另外一個 RM 的 xid 也爲 1，就代表這 2 個 RM 在一個全局事務上。

TM 創建一個 xid 規定哪些分支事務屬於當前這個全局事務。

TM 向 TC 發起提交或回滾全局事務的請求，把全局事務 id 綁定在分支事務上，代表在一個全局事務中。

具體的 RM 需要向 TC 進行註冊，告訴 TC 我當前的執行情況，成功了還是失敗了，再由 TC 告訴 RM 是提交還是回滾，這是整個的 Seata XA 事務模式。

Seata XA 事務模式也是 2PC 模式，

• 執行階段：執行分支事務並保證執行結果且滿足可回滾和可持久化

• 完成階段：TM 根據執行階段的結果形成決議，應用通過 TM 發起全局提交或回滾請求給 TC，TC 命令 RM 驅動分支事務進行提交或回滾。

回顧AT事務模式

AT 模式是 2PC 的變種，TM 進行全局事務提交和回滾，TM 給具體的分支事務加 xid，告訴當前分支事務屬於這一個全局事務，這部分 AT 和 XA 都是一樣的。

AT 模式解析 sql 語句，所以在第一階段（執行階段），解析當前 sql 的結果並且記錄 undolog 日誌。

首先 RM 分支事務進行註冊到 TC 中，告訴 TC 當前分支事務的執行結果是 yes 還是 no。

最終由 TC 告訴分支事務，誰失敗就需要回滾，回滾的時候用到了 undolog，根據 undolog 記錄的修改之前的數據來進行反向的補償更新，這是第二階段。如果都是 yes，就進行整體的提交。TM 負責全局的事務開啓和提交、回滾操作，TC 告訴具體的分支事務是提交還是回滾。

1、執行階段

• 可回滾：根據 sql 解析結果，記錄回滾日誌 undolog

• 持久化：把日誌記錄到數據庫中

2、完成階段

• 提交的時候異步刪除回滾日誌

• 回滾的時候，根據回滾日誌反向補償

Seata XA模式

Seata XA 模式就是把 XA 協議歸納到 Seata 中，在 Seata 定義的分佈式事務架構內，利用數據庫、消息服務等對 XA 的支持，以 XA 協議的機制來管理分佈式事務的一種機制。

Seata XA、AT、 SAGA、TCC 都是遵循整個 Seata 事務模式來進行的。

XA 模式開啓，執行 sql，XA 模式結束，這是 XA 的準備階段，第二階段是 XA 進行提交或回滾。

在 Seata 的 XA 模式與 AT 的區別是 XA 沒有 undolog。

AT 記錄了 undolog，根據 undolog 反向補償，達到最終一致性。

XA 是強一致性，通過數據庫的 ACID 執行的，沒有中間狀態。

最終一致性存在中間狀態，XA 不存在中間狀態，XA 是強一致性的。

第一階段是執行階段，保證可回滾和持久化，XA 模式對 sql 進行解析後告訴 TC 每個分支事務當前執行的情況，TC 來決定是提交還是回滾。

把 AT 替換成了 XA，整個的 Seata 的分佈式事務框架不變，只不過 AT 變成了強一致性的 XA。

可回滾是指在 XA 分支中進行業務 sql 的執行，由數據庫資源對 XA 協議支持來保證可回滾，即依賴數據源自帶的事務的 ACID 來進行回滾。

持久化是指 XA 分支在執行完成以後，即 XA start 和 end 完成之後，由數據庫資源進行持久化，可以保證任何意外都不會造成無法回滾的情況，這樣就解決了 XA 協議的核心痛點。

mysql 和 oracle 都支持 XA 協議，都支持本地事務，可以保證在任何情況下數據的持久性。

XA的價值

Seata 已經支持了 3 大事務模式 AT、SAGA、TCC，爲什麼還要支持 XA?

這 3 個都是補償型的，存在中間狀態。

構建在事務資源之上的模型，要麼在中間件層面實現，要麼在應用層面實現，事務資源本身對分佈式事務是無感知的。

所謂的事務資源是本地事務，本地事務對分支事務是無法感知的，無法做到真正的全局一致性，即存在中間狀態。

比如一個庫存當前是 100，扣 50，還剩 50，倉庫管理員連接數據庫查看當前結果，讀到的是 50，由於當前這個事務出現了問題，回滾了，50 回滾到 100 了。

倉庫管理員讀到的是 50，就產生了髒讀，所謂的髒數據是中間狀態，管理員再次連接數據庫可以拿到回滾之後的數據。數據 50 是中間的狀態，100 是最終一致性的狀態。

AT 模式：訂單下單之後，100 個庫存扣減 1 還剩 99，訂單創建失敗了，需要整個全局回滾，undolog 中會記錄之前的值 100 ，但是在事務執行的過程中，會存在 99 的狀態。如果庫存減 1 了，訂單並沒有真正創建，這個時候讀庫存，讀到的確實是 99，這個 99 就是所謂的中間狀態，這個就是髒讀。

AT、SAGA、TCC 都是補償型的，都會出現髒讀的情況，當然 Seata 本身是有預防的，但確實會存在這些問題：可能會得到髒數據且最終一致性是允許有中間狀態的，這也解釋了爲什麼 Seata 支持 XA，因爲 XA 是強一致性的。

XA 沒有 undolog 日誌，也不會暴露中間狀態。

與補償型不同，事務資源本身提供對 XA 規範和協議的支持，事務資源感知並參與分佈式事務處理的過程。

數據資源（數據庫） 可以保證從任意視角對數據庫訪問可以有效的隔離且滿足全局事務的一致性。

補償型的事務模型會出現中間狀態，當想做到強一致性的時候就需要 XA。

XA 由數據庫本身保證，不會出現倉庫管理員查詢看到中間狀態的情況，這是由本地事務隔離性保證的。

除了強一致性這個優點，還有無業務侵入、數據庫支持廣泛、多語言的支持、不涉及到 sql 解析、XA 模式對 Seata 的 RM 要求比較少、傳統的 XA 模式應用可以平滑遷移到 Seata 平臺的優點。

一致性、可靠性、易用性、性能等系統設計約束需要不同的事務處理機制去完成，Seata 提供了全面解決分佈式事務問題的標準化平臺。

無業務侵入的有 AT 和 XA，有業務侵入的有 TCC、 SAGA，XA 模式的加入補全了 Seata 在全局一致性下的缺口。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/rNqKR90ndk15mJpimw4JYw