解决分布式事务的方案有很多,但实现起来都比较复杂,因此我们一般会使用开源的框架来解决分布式事务问题。
在众多的开源分布式事务框架中,功能最完善、使用最多的就是阿里巴巴在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发起一个请求,去注册全局事务,接下来,就可以去执行这个入口的业务逻辑了,去调用每一个微服务,到了微服务里面每个分支事务就要开始执行了,