Seata框架是一個業務層的XA（兩階段提交）解決方案。在理解Seata分布式事務機制前，我們先回顧一下數據庫層面的XA方案。
Seata 是一款開源的分布式事務解決方案，致力於提供高性能和簡單易用的分布式事務服務。Seata 將為用戶提供了 AT、TCC、SAGA 和 XA 事務模式，為用戶打造一站式的分布式解決方案。
1. MySQL XA方案
- RM（Resource Manager）：用於直接執行本地事務的提交和回滾。在分布式集群中，一台MySQL服務器就是一個RM。
- TM（Transaction Manager）：TM是分布式事務的核心管理者。事務管理器與每個RM進行通信，協調並完成分布式事務的處理。發起一個分布式事務的MySQL客戶端就是一個TM。
XA的兩階段提交分為Prepare階段和Commit階段，過程如下：
- 階段一為准備（prepare）階段。即所有的RM鎖住需要的資源，在本地執行這個事務（執行sql，寫redo/undo log等），但不提交，然后向Transaction Manager報告已准備就緒。
- 階段二為提交階段（commit）。當Transaction Manager確認所有參與者都ready后，向所有參與者發送commit命令。
MySQL XA擁有嚴重的性能問題。一個數據庫的事務和多個數據庫間的XA事務性能對比可發現，性能差10倍左右。另外，XA過程中會長時間的占用資源（加鎖）直到兩階段提交完成才釋放資源。
2. Seata
Seata的分布式事務解決方案是業務層面的解決方案，只依賴於單台數據庫的事務能力。Seata框架中一個分布式事務包含3中角色：
- Transaction Coordinator (TC)： 事務協調器，維護全局事務的運行狀態，負責協調並驅動全局事務的提交或回滾。
- Transaction Manager (TM)： 控制全局事務的邊界，負責開啟一個全局事務，並最終發起全局提交或全局回滾的決議。
- Resource Manager (RM)： 控制分支事務，負責分支注冊、狀態匯報，並接收事務協調器的指令，驅動分支（本地）事務的提交和回滾。
其中，TM是一個分布式事務的發起者和終結者，TC負責維護分布式事務的運行狀態，而RM則負責本地事務的運行。如下圖所示：
下面是一個分布式事務在Seata中的執行流程：
- TM 向 TC 申請開啟一個全局事務，全局事務創建成功並生成一個全局唯一的 XID。
- XID 在微服務調用鏈路的上下文中傳播。
- RM 向 TC 注冊分支事務，接着執行這個分支事務並提交（重點：RM在第一階段就已經執行了本地事務的提交/回滾），最后將執行結果匯報給TC。
- TM 根據 TC 中所有的分支事務的執行情況，發起全局提交或回滾決議。
- TC 調度 XID 下管轄的全部分支事務完成提交或回滾請求。
可以看到分布式事務還是會有各種問題，一般分布式事務的實現還是只能達到最終一致性。
極端情況下還是得人工介入，所以做好日志記錄很關鍵。
還有編碼的業務流程，要往利於公司的方向寫，就例如先拿到用戶的錢，再給用戶東西這個方向，切記。