Seata是阿里开源的一个分布式事务框架。
Seata主要有两种分布式事务实现方案，AT及TCC
AT模式主要关注多 DB 访问的数据一致性，当然也包括多服务下的多 DB 数据访问一致性问题
TCC 模式主要关注业务拆分，在按照业务横向扩展资源时，解决微服务间调用的一致性问题
AT模式/MT模式
Seata AT模式是基于XA事务演进而来的一个分布式事务中间件，XA是一个基于数据库实现的分布式事务协议，本质上和两阶段提交一样，需要数据库支持，Mysql5.6以上版本支持XA协议，其他数据库如Oracle，DB2也实现了XA接口。
AT不依赖与数据库本身对协议的支持，当然也不需要数据库支持 XA 协议。这点对于微服务化的架构来说是非常重要的：应用层不需要为本地事务和分布式事务两类不同场景来适配两套不同的数据库驱动。
原理
seate.png
XA.png
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表：用于分支事务的回滚
执行过程图
![
seata_at-2.png
特别注意的是：
回滚时通过 XID 和 Branch ID 查找到相应的 UNDO LOG 记录并校验。
数据校验：拿 UNDO LOG 中的后镜与当前数据进行比较，如果有不同，说明数据被当前全局事务之外的动作做了修改。这种情况，需要根据配置策略来做处理，详细的说明在另外的文档中介绍。
业务更新 ssql与插入到UNDO_LOG 表镜像数据是同一个数据。
问题：
最大的问题：事务隔离级别最高支持到 读已提交 的水平，SQL 的解析还不能涵盖全部的语法等。
问题一：隔离性减弱：隔离级别变为读未提交
在数据库本地隔离级别 读已提交 或以上的前提下，Fescar 设计了由事务协调器维护的 全局写排他锁，来保证事务间的 写隔离，将全局事务默认定义在 读未提交 的隔离级别上。
我们对隔离级别的共识是：微服务场景产生的分布式事务，绝大部分应用在 读已提交 的隔离级别下工作是没有问题的。而实际上，这当中又有绝大多数的应用场景，实际上工作在 读未提交 的隔离级别下同样没有问题。
问题二：回滚时数据已被改变
回滚时通过 XID 和 Branch ID 查找到相应的 UNDO LOG 记录并校验。
数据校验：拿 UNDO LOG 中的后镜与当前数据进行比较，如果有不同，说明数据被当前全局事务之外的动作做了修改。这种情况，需要根据配置策略来做处理。
解决方式： 脏数据需手动处理，根据日志提示修正数据或者将对应undo删除(可自定义实现FailureHandler做邮件通知或其他)
注：建议事前做好隔离保证无脏数据(加分布式锁)
官网：
引用