Seata是阿里開源的一個分布式事務框架。
Seata主要有兩種分布式事務實現方案，AT及TCC
- AT模式主要關注多 DB 訪問的數據一致性，當然也包括多服務下的多 DB 數據訪問一致性問題
- TCC 模式主要關注業務拆分，在按照業務橫向擴展資源時，解決微服務間調用的一致性問題
AT模式/MT模式
Seata AT模式是基於XA事務演進而來的一個分布式事務中間件，XA是一個基於數據庫實現的分布式事務協議，本質上和兩階段提交一樣，需要數據庫支持，Mysql5.6以上版本支持XA協議，其他數據庫如Oracle，DB2也實現了XA接口。
AT不依賴與數據庫本身對協議的支持，當然也不需要數據庫支持 XA 協議。這點對於微服務化的架構來說是非常重要的：應用層不需要為本地事務和分布式事務兩類不同場景來適配兩套不同的數據庫驅動。
原理
- Transaction Coordinator (TC)： 事務協調器，維護全局事務的運行狀態，負責協調並驅動全局事務的提交或回滾。
- Transaction Manager (TM)： 控制全局事務的邊界，負責開啟一個全局事務，並最終發起全局提交或全局回滾的決議。
- Resource Manager (RM)： 控制分支事務，負責分支注冊、狀態匯報，並接收事務協調器的指令，驅動分支（本地）事務的提交和回滾。
使用
- 創建Seata TC Server服務
Seata TC Server的 db 數據庫為：
（1）global_table ：the table to store GlobalSession data
（2）branch_table：the table to store BranchSession data
（3）lock_table：the table to store lock data - 使用方數據庫增加undo_log表：用於分支事務的回滾
- 方法上增加@GlobalTransactional注解
Dubbo 分布式事務 Seata 入門 | 芋道源碼 —— 純源碼解析博客
執行過程圖
特別注意的是：
- 回滾時通過 XID 和 Branch ID 查找到相應的 UNDO LOG 記錄並校驗。
數據校驗：拿 UNDO LOG 中的后鏡與當前數據進行比較，如果有不同，說明數據被當前全局事務之外的動作做了修改。這種情況，需要根據配置策略來做處理，詳細的說明在另外的文檔中介紹。 - 業務更新 ssql與插入到UNDO_LOG 表鏡像數據是同一個數據。
- 整個過程 全局鎖 在 tx1 結束前一直是被 tx1 持有的，所以不會發生 臟寫 的問題。
http://seata.io/zh-cn/docs/overview/what-is-seata.html
問題：
最大的問題：事務隔離級別最高支持到 讀已提交 的水平，SQL 的解析還不能涵蓋全部的語法等。
問題一：隔離性減弱：隔離級別變為讀未提交
在數據庫本地隔離級別 讀已提交 或以上的前提下，Fescar 設計了由事務協調器維護的 全局寫排他鎖，來保證事務間的 寫隔離，將全局事務默認定義在 讀未提交 的隔離級別上。
我們對隔離級別的共識是：微服務場景產生的分布式事務，絕大部分應用在 讀已提交 的隔離級別下工作是沒有問題的。而實際上，這當中又有絕大多數的應用場景，實際上工作在 讀未提交 的隔離級別下同樣沒有問題。
問題二：回滾時數據已被改變
回滾時通過 XID 和 Branch ID 查找到相應的 UNDO LOG 記錄並校驗。
數據校驗：拿 UNDO LOG 中的后鏡與當前數據進行比較，如果有不同，說明數據被當前全局事務之外的動作做了修改。這種情況，需要根據配置策略來做處理。
解決方式： 臟數據需手動處理，根據日志提示修正數據或者將對應undo刪除（可自定義實現FailureHandler做郵件通知或其他）
注：建議事前做好隔離保證無臟數據（加分布式鎖）
概覽 · seata/seata Wiki · GitHub
官網：
Seata 是什么
概覽 · seata/seata Wiki · GitHub
Seata 極簡入門
引用
Seata簡介(附帶與其他分布式事務解決方案對比)數據庫古柏樹下的博客-CSDN博客
seata分布式事務原理解釋，AT模式簡介_tianyaleixiaowu的專欄-CSDN博客_seata分布式事務原理
阿里開源分布式事務組件 seata : AT 模式的分支事務處理 - beanlam - SegmentFault 思否