【分布式事务解决方案--Seata简介】

分布式事务解决思路：
分布式事务最大的问题是各个子事务的一致性问题，因此可以借鉴 CAP定理 和 BASE理论，有两种解决思路

AP 模式（最终一致性思想）：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。
CP 模式（强一致性思想）：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。

1.seata简介

seata为2019年1月份蚂蚁金服和阿里巴巴共同开源得分布式事务解决方案。

2.seata相关概念

分布式事务处理过程的一ID+三组件模型，一ID即Transaction ID XID，全局唯一的事务ID。

三组件：

1.TC (Transaction Coordinator) - 事务协调者

维护全局和分支事务的状态，驱动全局事务提交或回滚。

2.TM (Transaction Manager) - 事务管理器

定义全局事务的范围：开始全局事务、提交或回滚全局事务。

3.RM (Resource Manager) - 资源管理器

管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚

下图则为组件工作流程图


分为以下几步：

1）TM开启分布式事务（TM向TC注册全局事务记录）；

2）按业务场景，编排数据库，服务等事务内资源（RM向TC汇报资源准备状态）

3）TM结束分布式事务，事务一阶段结束（TM通知TC提交、回滚分布式事务）

4）TC汇总事务信息，决定分布式事务是提交还是回滚

5）TC通知所有RM提交或回滚资源，事务二阶段结束

那么TM是如何开启事务呢？

以上就会用到注解@GlobalTransaction，说人话：注解贴在谁身上，谁就是TM负责开启事务。

3.Seata 默认AT（Auto Transaction）模式

Seata 基于上述架构提供了四种不同的分布式事务解决方案

XA 模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入
TCC 模式：最终一致的分阶段事务模式，有业务侵入
AT 模式：最终一致的分阶段事务模式，无业务侵入，也是 Seata 的默认模式
SAGA 模式：长事务模式，有业务侵入


seata默认使用为AT模式，AT模式如何做到业务无侵入呢？

一阶段加载：

这里可以理解为Spring的AOP思想，类似于前置通知和后置通知。

二阶段提交：

二阶段回滚：

具体流程如下图：
![在这里插入图片描述](https://img-blog.csdnimg.cn/3afdf332e37f4517b4a119530f7ac7c1.png

如图：开启事务生成唯一事务ID，并记录表内，Branch_id负责记录各个服务对应的分支id，lock记录事务中被锁的表数据。

4.总结

AT、TCC、Saga、XA 模式分析

四种分布式事务模式，分别在不同的时间被提出，每种模式都有它的适用场景：

AT 模式是无侵入的分布式事务解决方案，适用于不希望对业务进行改造的场景，几乎0学习成本。

TCC 模式是高性能分布式事务解决方案，适用于核心系统等对性能有很高要求的场景。（TCC需要注意三种异常处理分别是空回滚、幂等、悬挂）

Saga 模式是长事务解决方案，适用于业务流程长且需要保证事务最终一致性的业务系统，Saga 模式一阶段就会提交本地事务，无锁，长流程情况下可以保证性能，多用于渠道层、集成层业务系统。事务参与者可能是其它公司的服务或者是遗留系统的服务，无法进行改造和提供 TCC 要求的接口，也可以使用 Saga 模式。

XA模式是分布式强一致性的解决方案，但性能低而使用较少。

在AT、TCC、SAGA 和 XA 这四种事务模式中使用最多，最方便的就是 AT 模式。与其他事务模式相比，AT 模式可以应对大多数的业务场景，且基本可以做到无业务入侵，开发人员能够有更多的精力关注于业务逻辑开发。

任何应用想要使用Seata的 AT 模式对分布式事务进行控制，必须满足以下 2 个前提：
1、必须使用支持本地 ACID 事务特性的关系型数据库，例如 MySQL、Oracle 等；
2、应用程序必须是使用 JDBC 对数据库进行访问的 JAVA 应用。