2021-02-02

Seata处理分布式事务

一、分布式事务问题

单机单库没这个问题
分布式前：从1:1-> 1:N-> N:N
分布式后：
分布式事务问题：一次业务操作需要跨多个数据源或需要跨多个系统进行远程调用，就会产生分布式事务问题。

单体应用被拆分成微服务应用，原来的三个模块被拆分成三个独立的应用，分别使用三个独立的数据源。
业务操作需要调用三个服务来完成。此时每个服务内部的数据一致性由本地事务来保证，但是全局的数据一致性问题没法保证。
用户购买商品的业务逻辑。整个业务逻辑由3个微服务提供支持：

仓储服务：对给走的商品扣除仓储数量。
订单服务：根据采购需求创建订单。
帐户服务：从用户帐户中扣除余额。

二、简介

2.1、关于

Seata是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。
官网地址：http://seata.io/zh-cn/

2.2、作用

一个典型的分布式事务过程

1、分布式事务处理过程的 ID + 三组件模型

Transaction ID XID 全局唯—的事务ID
3组件概念
- Transaction Coordinator(TC)
  事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚；
- Transaction Manager(TM)
  控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议；
- Resource Manager(RM)
  控制分支事务，负责分支注册，状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚；

2、处理过程

1、TM 向 TC 申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的 XID；
2、XID 在微服务调用链路的上下文中传播；
3、RM向TC注册分支事务,将其纳入XID对应全局事务的管辖;
4、TM 向TC 发起针对 XID 的全局提交或回滚决议;
5、TC 调度 XID 下管辖的全部分支事务完成提交或回滚请求。

SEATA的分布式交易解决方案：

三、Seata-Server 安装

1、官网地址：http://seata.io/zh-cn/
2、下载版本。
3、seata-server-0.9.0.zip解压到指定目录并修改conf目录下的 file.conf 配置文件

先备份原始file.conf文件。
主要修改：自定义事务组名称 + 事务日志存储模式为db + 数据库连接信息。

4、mysql5.7 数据库新建库 seataSQL。
5、在 seata 库里建表。

建表db_store.sql在\seata-server-0.9.0\seata\conf目录里面

6、修改seata-server-0.9.0\seata\conf目录下的registry.conf配置文件
7、先启动Nacos端口号8848。
8、再启动seata-server。

四、Seata原理简介

4.1、Seata

2019年1月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。
Simple Extensible Autonomous Transaction Architecture，简单可扩展自治事务框架。

4.2、TC/TM/RM三大组件

分布式事务的执行流程：

TM开启分布式事务(TM向TC注册全局事务记录)
换业务场景,编排数据库,服务等事务内资源(RM向TC汇报资源准备状态)
TM结束分布式事务,事务一阶段结束(TM通知TC提交/回滚分布式事务)
TC汇总事务信息，决定分布式事务是提交还是回滚。
TC通知所有RM提交/回滚资源，事务二阶段结束。

4.3、AT模式如何做到对业务的无侵入

4.3.1、AT模式

1、前提

基于支持本地 ACID 事务的关系型数据库。
Java 应用，通过 JDBC 访问数据库。

2、整体机制
两阶段提交协议的演变：
一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。
二阶段:
提交异步化，非常快速地完成。
回滚通过一阶段的回滚日志进行反向补偿。

4.3.2、一阶段加载

在一阶段，Seata 会拦截 业务SQL 。

1、解析SQL语义，找到业务SQL要更新的业务数据，在业务数据被更新前，将其保存成before image。
2、执行业务SQL更新业务数据，在业务数据更新之后，更新后的数据也保存一份。
3、其保存成after image ，最后生成行锁。

以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。

4.3.3、二阶段提交

二阶段如是顺利提交的话，因为业务SQL在一阶段已经提交至数据库，所以Seata框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。

4.3.4、二阶段回滚

二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的业务SQL，还原(补偿)业务数据。
回滚方式便是用before image还原业务数据。但在还原前要首先要校验脏写，对比数据库当前业务数据和after image如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。(就是，可能在回滚之前，其他请求已经成功修改过这条数据，那么当前就不能回滚了)

暂无