分布式事務三--AT模式

Seata介紹

Seata 是一款開源的分布式事務解決方案，致力於提供高性能和簡單易用的分布式事務服務。Seata 將為用戶提供了 AT、TCC、SAGA 和 XA 事務模式，為用戶打造一站式的分布式解決方案。

2019 年 1 月，阿里巴巴中間件團隊發起了開源項目 Fescar（Fast & EaSy Commit And Rollback），和社區一起共建開源分布式事務解決方案。Fescar 的願景是讓分布式事務的使用像本地事務的使用一樣，簡單和高效，並逐步解決開發者們遇到的分布式事務方面的所有難題。

Fescar 開源后，螞蟻金服加入 Fescar 社區參與共建，並在 Fescar 0.4.0 版本中貢獻了 TCC 模式。

為了打造更中立、更開放、生態更加豐富的分布式事務開源社區，經過社區核心成員的投票，大家決定對 Fescar 進行品牌升級，並更名為 Seata，意為：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事務解決方案。

Seata 融合了阿里巴巴和螞蟻金服在分布式事務技術上的積累，並沉淀了新零售、雲計算和新金融等場景下豐富的實踐經驗，但要實現適用於所有的分布式事務場景的願景，仍有很長的路要走。

Seata AT事務方案

Seata 的 AT 模式（Automatic Transaction）是一種無侵入的分布式事務解決方案。下面結合具體業務場景來分析其執行的原理。

業務場景

訂單系統

當用戶下訂單時，執行以下三步流程：

1. 訂單系統保存訂單
2. 訂單系統調用庫存服務，減少商品庫存
3. 訂單系統調用賬戶服務，扣減用戶金額

這三步要作為一個整體事務進行管理，要么整體成功，要么整體失敗。

Seata AT基本原理

Seata AT 事務分兩個階段來管理全局事務：
第一階段： 執行各分支事務
第二階段： 控制全局事務最終提交或回滾

第一階段：執行各分支事務

微服務系統中，各服務之間無法相互感知事務是否執行成功，這時就需要一個專門的服務，來協調各個服務的運行狀態。這個服務稱為 TC（Transaction Coordinator），事務協調器。

訂單系統開始執行保存訂單之前，首先啟動 TM（Transaction Manager，事務管理器），由 TM 向 TC 申請開啟一個全局事務：

這時TC會產生一個全局事務ID，稱為 XID，並將 XID 傳回 TM：

這樣就開啟了全局事務！

全局事務開啟后，開始執行創建訂單的業務。首先執行保存訂單，這時會先啟動一個 RM（Resource Manager，資源管理器），並將 XID 傳遞給 RM。

RM 負責對分支事務（即微服務的本地事務）進行管理，並與 TC 通信，上報分支事務的執行狀態、接收全局事務的提交或回滾指令。

RM 首先會使用 XID 向 TC 注冊分支事務，將分支事務納入對應的全局事務管轄。

現在可以執行保存訂單的分支事務了。一旦分支事務執行成功，RM 會上報事務狀態：

TC 收到后，會將該狀態信息傳遞到 TM：

到此，保存訂單過程結束。然后就是調用庫存服務，減少商品庫存，與訂單的執行過程相同。

首先調用庫存服務，啟動 RM，並傳遞 XID：

庫存服務的 RM 使用 XID 向 TC 進行注冊，納入全局事務管轄：

執行本地事務成功后上報狀態，TC會將狀態發送給TM：

相同的，完成賬戶分支事務：

第二階段：控制全局事務最終提交

現在，TM（全局事務管理器）收集齊了全部分支事務的成功狀態，它會進行決策，確定全局事務成功，向 TC 發送全局事務的提交請求：

然后，TC 會向所有 RM 發送提交操作指令，RM 會完成最終提交操作：

到此，全局事務全部提交完成！

第二階段：控制全局事務最終回滾

上面是全局事務執行成功的情況，下面再來看看事務執行失敗的情況。

假設訂單業務執行過程中，扣減賬戶金額這一步分支事務執行失敗，那么失敗狀態對TC上報，然后再發送給TM：

TM 會進行決策，確定全局事務失敗，向 TC 發送全局事務的回滾請求：

然后，TC 會向所有 RM 發送回滾操作指令，RM 會完成最終回滾操作：

Seata AT具體工作機制

以上了解了 Seata AT 的基本原理、工作流程，那么 Seata 具體是如何實現全局事務的提交和回滾操作呢？下面來分析 Seata 的具體工作機制。

第一階段：執行分支事務

以全面訂單業務中的庫存服務為例，庫存表中存在一條商品的庫存信息：

現在要執行業務操作減少庫存，從50件減少到40件：

執行修改庫存業務操作前， 會先取出舊的庫存信息：

現在可以修改庫存了：

接着，取出更新后的新數據：

接下來，會把舊數據和新數據合並起來，保存到一個事務回滾日志表：undo_log表：

至此，第一階段，分支事務完成，將狀態上報給TC：

第二階段：控制全局事務最終回滾

假如全局事務失敗，那么第一階段已提交的分支事務要執行回滾操作。

首先會收到來自 TC 的全局事務回滾指令：

接下來，根據事務回滾日志（undo_log）表的記錄，將商品恢復成舊的庫存數據：

然后刪除事務日志，最終完成第二階段回滾操作：

第二階段：控制全局事務最終提交

上面是全局事務回滾操作。如果全局事務成功，要完成最終提交，AT模式最終提交操作非常簡單，只需要刪除日志數據即可。

首先接收到 TC 的全局事務提交指令：

接着，直接刪除事務日志，就完成了第二階段提交操作：

至此完成了事務的提交。