深入学习Seata（一）：什么是Seata

微服务与分布式事务

分布式事务是随着服务拆分而产生的问题，至于为什么要做服务拆分以及什么是微服务，可以参考下这里 我们知道对于分布式场景而言，肯定是遵循CAP理论的，所以对于这种情况下的事务而言，跨多个服务的调用事务则成了一个令人头疼的点，而Seata则是一个用于解决分布式环境下事务的框架。

Seata历史介绍

Seata是阿里开发的一个用于微服务架构的高性能易使用的分布式事务框架。 Seata由TXC（Taobao Transaction Constructor，阿里于2014开始着手解决分布式事务的内部框架）-》GTX（Global Transaction Service，阿里于2016年将TXC发布于云服务并且改名为GTX）-》Fescar（阿里于2019将GTS开源并改名为Fescar）-》Seata（Simple Extensible Autonomous Transaction Architecture，阿里将蚂蚁金服框架DTX与Fescar结合并且改名为Seata） 目前Seata已经是github上一个大热的项目，年初开源，现在发布至0.8.0版本，已经有11000的star数，并且在快速的更新迭代。 相信未来会是一个普遍的分布式事务解决方案。

Seata架构

Seata目前的事务模式有AT，TCC，Saga三种模式，默认即是AT模式，AT本质上是2pc协议的一种实现，三种模式的不同后面文章再详细介绍。 这里我们简单介绍下Seata是如何解决分布式事务的

假设我们现在有一个商品购物的业务，对于后台系统而言有四个服务，Business(业务入口)，Storage（库存服务），Order（订单服务），Account（用户服务），用户通过Business购买商品下单，在系统内部会经历以下流程：

如图所示，Business通过rpc框架（dubbo，feign....)调用其他服务。Seata将上面整个调用链所产生的事务结合生成了一个全局事务：

如图所示，对于全局事务而言，它由各个分支事务结合而成，而分支事务则代表一个服务的本地事务。

对于每个服务来说，代表了两种角色：

如图所示，对于每一个服务而言都有两种角色（TM，RM）,在全局事务的过程中，它们会与TC进行通信协助完成整个事务，可以简单介绍下每个角色的作用: TC： Transaction Coordinator，事务协调器：监视每个全局事务的状态，负责全局事务的提交和回滚。 TM: Transaction Manager, 事务管理者：向TC发起，提交，回滚全局事务的请求。 RM: Resource Manager, 资源管理器：服务向TC发起，提交，报告分支事务的请求，并且服务本地事务的回滚，提交。

Seata处理一个全局事务的流程如下：

1. TM向TC请求发起一个全局事务，TC返回一个代表这个全局事务的XID。
2. XID在rpc中传播给每一个调用链中的服务。
3. 每个RM拿到XID后向TC发起一个分支事务，TC返回一个代表这个分支事务的XID。
4. RM完成本地分支的业务，提交本地分支，并且报告给TC。
5. 全局事务调用链处理完毕，TM根据有无异常向TC发起全局事务的提交或者回滚。

回滚：

6. 假设某个RM本地事务失败。该RM自身驱动本地事务回滚，并且报告给TC。
7. TM检测到了某个分支事务失败，向TC发起全局事务回滚。
8. TC给每一个RM发送消息，通知它们全部回滚。
9. TC将全局事务回滚的结果发送给TM。 全局事务结束。

   

总结

1. 社区活跃，短短几个月时间star数已经上W，目前已经更新0.8版本，到1.0版本可供线上环境使用。
2. 灵活，对于seata的使用而言，使用非常简单，特别对于AT模式来说，几乎只要加一个注解就能实现分布式事务。
3. 高性能，虽然对于使用2pc协议的一个最大诟病就是性能问题，多个库同时锁定造成性能的急剧下降。 而seata在这个基础上有较大的提升，特别对于tcc模式而言。 而目前AT模式只会
4. 目前TC还不支持集群部署，一旦TC宕机，整个系统分布式事务全都无法处理