两个内容：
1.Seata 原理
AT模式(业务侵入小)
Seata AT模式是基于XA事务演进而来的一个分布式事务中间件，XA是一个基于数据库实现的分布式事务协议，本质上和两阶段提交一样，需要数据库支持，Mysql5.6以上版本支持XA协议，其他数据库如Oracle，DB2也实现了XA接口
角色如下
Transaction Coordinator (TC)： 事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚
Transaction Manager ™： 控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议
Resource Manager (RM)： 控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚
基本处理逻辑如下
Branch就是指的分布式事务中每个独立的本地局部事务
第一阶段
Seata 的 JDBC 数据源代理通过对业务 SQL 的解析，把业务数据在更新前后的数据镜像组织成回滚日志，利用 本地事务 的 ACID 特性，将业务数据的更新和回滚日志的写入在同一个 本地事务 中提交。
这样，可以保证：任何提交的业务数据的更新一定有相应的回滚日志存在
基于这样的机制，分支的本地事务便可以在全局事务的第一阶段提交，并马上释放本地事务锁定的资源
这也是Seata和XA事务的不同之处，两阶段提交往往对资源的锁定需要持续到第二阶段实际的提交或者回滚操作，而有了回滚日志之后，可以在第一阶段释放对资源的锁定，降低了锁范围，提高效率，即使第二阶段发生异常需要回滚，只需找对undolog中对应数据并反解析成sql来达到回滚目的
同时Seata通过代理数据源将业务sql的执行解析成undolog来与业务数据的更新同时入库，达到了对业务无侵入的效果
第二阶段
如果决议是全局提交，此时分支事务此时已经完成提交，不需要同步协调处理（只需要异步清理回滚日志），Phase2 可以非常快速地完成
如果决议是全局回滚，RM 收到协调器发来的回滚请求，通过 XID 和 Branch ID 找到相应的回滚日志记录，通过回滚记录生成反向的更新 SQL 并执行，以完成分支的回滚
TCC(高性能)
seata也针对TCC做了适配兼容，支持TCC事务方案，原理前面已经介绍过，基本思路就是使用侵入业务上的补偿及事务管理器的协调来达到全局事务的一起提交及回滚，详情参考demo回滚
2.Seata 源码分析：
重要流程如下：
拿到我们的主键，拿到更新的字段，
拿到更新的where 添加：
模板方法:
1.主要看update 方法，
一张表描述另一张表：
row_key,xid,table-name,bracnhedID:
2.分布式分析：
模板方法：
全局提交
----------------------------------------
总得来说就是分为如下几步
业务方调用各个微服务的try()方法，执行资源检查及预留操作
当所有try()方法均执行成功时，对全局事物进行提交，即由事物管理器调用每个微服务的confirm()方法
当任意一个方法try()失败(预留资源不足，抑或网络异常，代码异常等任何异常)，由事物管理器调用每个微服务的cancle()方法对全局事务进行回滚
资源预留、提交、回滚都由业务方编码控制写在try()、confirm()、cancle()中
关键点就是： TCC事务协调器如何知道在业务方调用各个微服务的try()后，是该调用confirm还是cancle方法，以及具体调用哪个资源管理器(RM)的方法
至此第二个问题，TC如何找到该调用哪些机器上服务的confirm方法，rollback方法也解决了
基本思路就是
TM发起提交请求（带有xid）
TC通过xid找到全局session，再取出所有的分支session
通过分支session里的resourceId，去缓存中找到缓存的rpcContext对象，取出对应channel，建立通信
总结一下全局事务提交的大致流程
业务方调用微服务无异常，通过TM发起事务提交请求
TC接收到事务提交请求后，通过Xid找到全局事务，再取出所有的分支事务
遍历分支事务，发出分支事务提交请求
TCC资源管理器RM接收到提交请求后，从本地TCCResource缓存中根据resourceId取出对应方法bean，反射调用commit方法
源码分析：https://blog.csdn.net/f4761/article/details/89077400
参考博文：https://blog.csdn.net/f4761/article/details/89077400