学习资源来自姜宇的《正本清源分布式事务之Seata》
2.1 Seata总体架构
2.1.1 模块组成
Seata的目录结构说明如下：
- all: 只有一个pom文件，指定了Seata依赖的包。
- bom: 只有一个pom文件，指定了Seata依赖包的版本。
- changes: md文件描述版本变更情况。
- common: 通用模块。包括通用工具类、线程工具、异常、加载类等。
- compressor: 压缩模块。封装了各种压缩剩下，比如Zip、Gzip、7z、Lz4、Bzip2等，部分通过引入第三方依赖实现，此模块主要用于消息压缩。
- config: 配置模块。用于连接和操作配置中心，支持Nacos、Apollo、Etcd、Consul、ZooKeeper等。
- console: 用户控制台。应该是最近新加的模块，目前源码来看只是用于查看Seata是否还活着。
- core: 核心模块。定义了RPC、Nety、事件、协议、事务上下文等。
- discovery: 发现模块。用于服务发现，支持Nacos、Etcd、Eureka、Redis、ZooKeeper等。
- distribution: 只有一个pom文件，用于打包发布。
- ext/apm-seata-skywalking-plugin: 应该是用于对skywalking监控的支持。
- integration: 整合模块。整合了Seata对多种RPC框架的支持，包括Dubbo、gRPC、SOFA-RPC等。用来实现Seata事务上下文在RPC框架的传递。
- metrics: 度量模块。用于收集一些Seata运行指标数据，并导出到监控系统(如Prometheus)。
- rm: 资源管理模块。定义了多种类型资源管理器的公共组件，包括AT模式、TCC模式、Saga模式、XA模式的资源管理器。
- rm-datasource: AT模式的资源管理器模块。实现了AT模式的数据源代理、SQL语句处理等。该模块也包括对XA模式的支持。
- saga: Saga模式的资源管理器模块。用来实现对Saga模式事务的支持。
- script: 脚本模块。定义了需要的脚本文件和配置文件。
- seata-plugin: seata的一些插件定制，目前里面只有一个OracleTimestampJacksonSerializer
- seata-spring-autoconfigure: spring自动装配
- seata-spring-boot-starter: 用于与Spring Boot结合，简化使用。
- serializer: 序列化模块。用于Seata消息序列化和反序列化，支持多种协议，包括Seata私有的序列化协议、FST、Hessian、Kryo等。
- server: 服务端模块。用来实现事务协调器，维护全局事务和分布式事务的状态，推进事务两阶段提交/回滚。
- spring: Spring支持模块。定义了Seata事务注解。
- sqlparser: SQL解析模块。Seata使用Druid SQL解释器。
- style: 定义了代码规范。
- tcc: TCC模式资源管理器模块。用来实现对TCC事务模式的支持。
- test: 测试模块。
- tm: 事务协调器模块。定义了全局事务的范围、开启全局事务、提交/回滚全局事务。
斜体部分是我自己补充的，书中并没有。
2.1.2 逻辑结构
Seata有3个主要角色：TM(事务管理器Transaction Manager)、RM(资源管理器Resource Manager)和TC(事务协调器Transaction Coordinator)。
其中，TM和RM是以SDK的形式作为Seata的客户端与业务系统集成在一起，TC作为Seata的服务的独立部署。
Seata处理分布式事务的主要流程：
(1) TM开启全局事务(TM向TC发起)。
(2) 事务参与者(应用)通过RM与资源交互(本地数据库执行事务但不提交)，并注册分支事务(RM向TC注册分支事务)。
(3) 事务参与者在完成资源操作后(提交)，上报分支事务状态(RM向TC上报分支事务状态)
(4) TM结束全局事务，事务一阶段结束(TM向TC发起提交/回滚全局事务)。
(5) TC推进事务二阶段操作(TC向TM发起二阶段提交/回滚)。
书中后面的篇章主要详细介绍AT和TCC模式，分布式事务流程大体一致，后面会有针对具体模式的详细流程。
2.2 Seata事务模式
Seata支持4中事务模式：AT、TCC、Saga、XA。
2.2.1 AT模式
AT模式是Seata主推的分布式事务解决方案，对业务无侵入，真正做到业务与事务分离，用户只需关注自己的“业务SQL语句”。
AT模式使用起来非常简单，与完全没有使用分布式事务方案相比，业务逻辑不需要修改，只需要增加注解@GlobalTransactional即可。
2.2.2 TCC模式
TCC模式需要用户根据自己的业务场景实现try()、confirm()和cancel()3个方法：事务发起方在一阶段执行try()方法，二阶段提交执行confirm()方法，回滚执行cancel()方法。
TCC模式与AT模式的主要区别：
(1) 在使用上，TCC模式依赖用户自行实现3个方法，成本较大；AT模式依赖全局事务注解和代理数据源，自动完成分布式事务的处理，成本低。
(2) TCC模式的作用范围在应用层，本质上是实现针对某种业务逻辑的正向和反向方法；AT模式的作用范围在底层数据源，通过保存操作行记录的前后镜像和生成反向SQL语句进行补偿操作，对上层应用透明。
(3) TCC模式事务并发控制需要自行实现加锁，AT模式由Seata框架自动加锁。
举例：
以扣钱的场景为例，业务上完成对账户扣钱这一个分支事务操作，只需要一条更新账户余额的SQL语句就能完成；但是如果接入TCC，用户需要考虑如何将一步拆成两阶段，实现成3个方法。
比如这样，扣钱场景中，try方法要做的是检查账户余额是否充足，预留转账资金(即冻结)。在try方法执行后，账户余额没有改变，但是其中一部分被冻结了，不能被其他事务使用。
二阶段confirm方法执行真正的扣钱操作，即扣掉try方法冻结的部分。
如果二阶段是回滚，则需要在cancel方法中释放一阶段try方法冻结的部分，使账户回到初始状态。
虽然相比AT模式，TCC模式对业务代码侵入性太强。但是TCC没有AT模式的全局行锁，加锁逻辑需要根据业务自行实现。因此TCC的性能会比AT模式更好，但如果用户在tCC中自行实现了加锁机制，这个优势就没有了。因此建议使用AT模式作为默认方案，TCC模式作为特殊处理的补充方案。
2.2.3 Saga模式
Saga理论来自Hector和Kenneth 1987年发表的论文SAGAS。
Saga是一种补偿协议，分布式事务内有多个参与者，每个参与者都要根据业务场景实现正向操作和逆向回滚操作。
在分布式事务执行过程中，会依次执行个参与者的正向操作。
- 如果所有正向操作均成功，则分布式事务提交。
- 如果任何一个正向操作执行失败，则分布式事务会退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。
Saga模式的正向服务和补偿服务都需要手动实现，因此有很强的侵入性。在Saga模式中，分布式事务通常是有事件驱动的，在各个参与者之间是异步执行的。
Saga模式是一种长事务解决方案，是用于业务流程长且需要保证事务最终一致性的业务系统。Saga模式的一阶段就会提交本地事务，在无锁、长流程下可以保证性能。
Saga的优势：
- 在一阶段提交本地事务，无锁，高性能。
- 参与者可以采用事件驱动异步执行，高吞吐。
- 补偿服务即正向服务的反向操作，易于理解和实现。
Saga模式也存在明显的缺点：在一阶段已经提交了本地事务，且没有进行预留动作，所以不能保证隔离性，不容易进行并发控制。与AT、TCC相比，适用场景有限。
2.2.4 XA模式
在XA模式中，需要在Seata定义的分布式范围内，利用事务资源(数据库、消息服务等)实现对XA协议的支持，以XA协议的戒指来管理分支事务。
本质上，Seata另外3中模式(AT、TCC、Saga)都是补偿型的。事务处理机制构建在框架或应用中，事务资源(数据库)本身对分布式事务是无感知的。而在XA模式下，事务资源对分布式事务是感知的。
XA协议要求事务资源本身提供对规范和协议的支持。因为事务资源可感知并参与分布式事务处理过程，所以事务资源可以保障从任何视角对数据访问进行有效隔离，满足全局数据一致性。
XA模式是传统分布式强一致性的解决方案，性能较低，在实际业务中使用较少。
网友评论