《Spring Cloud学习笔记：分布式事务Seata》

解决分布式事务的方案有很多，但实现起来都比较复杂，因此我们一般会使用开源的框架来解决分布式事务问题。

在众多的开源分布式事务框架中，功能最完善、使用最多的就是阿里巴巴在2019年开源的Seata了。 

1. 初识Seata

Seata是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。

Seata 可能给是目前已知最可靠的分布式事务解决方案。

官网地址：Seata | Seata，其中的文档、播客中提供了大量的使用说明、源码分析。

2. Seata的架构

其实分布式事务产生的一个重要原因，就是参与事务的多个分支事务互相无感知，不知道彼此的执行状态，因此解决分布式事务的思想非常简单：

• 就是找一个统一的事务协调者，与多个分支事务通信，检测每个分支事务的执行状态，保证全局事务下的每一个分支事务同时成功或失败接口，大多数的分布式事务框架都是基于这个理论来实现的。 

Seata也不例外，在Seata的事务管理中有三个重要的角色：

 

• TC（Transaction Coordinator）- 事务协调者：维护全局和分支事务的状态，协调驱动全局事务提交或回滚。
• TM（Transaction Manager）- 事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。
• RM（Resource Manager）- 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

其中，TC 为单独部署的 Server 服务端，TM 和 RM 为嵌入到应用中的 Client 客户端。 

在 Seata 中，一个分布式事务的生命周期如下： 

作为一个分布式事务，它肯定也会有一个入口方法，在这个入口方法当中，一定会去调用多个其它的微服务，每调一个微服务，这个微服务不就是一个分支事务，因此将来调了多少个微服务，将来我们这个全局事务就包含多少个分支事务，因此在这个入口方法里就定义了全局事务的范围了，而TM就会去监控这个入口的方法或者说是代理这个入口方法，这样一来，TM就知道了全局事务里面总共有多少个分支事务，整个范围就确定下来了，当入口方法被执行时，TM会首先拦截当前的这个执行，会去向TC发起一个请求，去注册全局事务，接下来，就可以去执行这个入口的业务逻辑了，去调用每一个微服务，到了微服务里面每个分支事务就要开始执行了，