Seata架构
Seata目前的事务模式有AT，TCC，Saga三种模式，默认即是AT模式，AT本质上是2pc协议的一种实现，三种模式的不同后面文章再详细介绍。
如图所示，对于每一个服务而言都有两种角色（TM，RM）,在全局事务的过程中，它们会与TC进行通信协助完成整个事务，可以简单介绍下每个角色的作用:
TC： Transaction Coordinator，事务协调器：监视每个全局事务的状态，负责全局事务的提交和回滚。
TM: Transaction Manager, 事务管理者：向TC发起，提交，回滚全局事务的请求。
RM: Resource Manager, 资源管理器：服务向TC发起，提交，报告分支事务的请求，并且服务本地事务的回滚，提交。
Seata处理一个全局事务的流程如下：
TM向TC请求发起一个全局事务，TC返回一个代表这个全局事务的XID。
XID在rpc中传播给每一个调用链中的服务。
每个RM拿到XID后向TC发起一个分支事务，TC返回一个代表这个分支事务的XID。
RM完成本地分支的业务，提交本地分支，并且报告给TC。
全局事务调用链处理完毕，TM根据有无异常向TC发起全局事务的提交或者回滚。
回滚：
假设某个RM本地事务失败。该RM自身驱动本地事务回滚，并且报告给TC。
TM检测到了某个分支事务失败，向TC发起全局事务回滚。
TC给每一个RM发送消息，通知它们全部回滚。
TC将全局事务回滚的结果发送给TM。 全局事务结束。
总结
seata社区活跃，短短几个月时间star数已经上W，目前已经更新0.8版本，到1.0版本可供线上环境使用。
灵活，对于seata的使用而言，使用非常简单，特别对于AT模式来说，几乎只要加一个注解就能实现分布式事务。
高性能，虽然对于使用2pc协议的一个最大诟病就是性能问题，多个库同时锁定造成性能的急剧下降。 而seata在这个基础上有较大的提升，特别对于tcc模式而言。 而目前AT模式只会
目前TC还不支持集群部署，一旦TC宕机，整个系统分布式事务全都无法处理
https://blog.csdn.net/hosaos/article/details/89136666?utm_source=app
这也是Seata和XA事务的不同之处，两阶段提交往往对资源的锁定需要持续到第二阶段实际的提交或者回滚操作，而有了回滚日志之后，可以在第一阶段释放对资源的锁定，降低了锁范围，提高效率，即使第二阶段发生异常需要回滚，只需找对undolog中对应数据并反解析成sql来达到回滚目的
同时Seata通过代理数据源将业务sql的执行解析成undolog来与业务数据的更新同时入库，达到了对业务无侵入的效果
