seata是什么

Seata 阿里巴巴由2019开源的一款分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。

 

在微服务架构中,每个服务都是独立的,所以服务的事务都是本地的,一个服务事务挂了,其他服务的事务已经提交的无法回滚,由此产生的脏数据(演示例子,商城用户下单->扣库存->扣余额->生成订单)

 

当order异常,product和user本地事务已经提交,就会产生脏数据,

 

seata处理方式 

 

 

 

 

seata 3个组件角色

 

 

官方介绍:

TC(Transaction Coordinator)-事务协调者:维护全局和分支事务的状态,驱动全局事务提交或回滚

TM(Transaction Manager)-事务管理器:定义全局事务范围,开始全局事务,提交或回滚全局事务

RM(Resource Manager)-资源管理器:控制分支事务，负责分支注册、状态汇报，并接收

事务协调器的指令，驱动分支（本地）事务的提交和回滚。

 

TC,TM,RM

流程

1.TM向 TC服务申请开始全局事务,成功后创建一个全局事务XID

2.XID在微服务的调用链路的上下文传播

3.RM 向TC注册分支事务并把XID绑定

4.TM根据TC所以分支执行情况,发起全局提交或者回滚请求

5.TC调度全部RM的分支事务完成提交或者回滚

 

XA协议

 由X/Open组织定义了分布式事务的模型，目的是允许多个资源（如数据库，应用服务器，消息队列，等等）在同一事务中访问，这样可以使ACID属性跨越应用程序而保持有效,目前知名的数据库，如Oracle, DB2,mysql等，都是实现了XA接口的，都可以作为RM。

 

支持XA协议数据库的分布式事务，强一致性，在整个过程中，数据一张锁住状态，即从prepare到commit、rollback的整个过程中，TM一直把持折数据库的锁，如果有其他人要修改数据库的该条数据，就必须等待锁的释放，存在长事务风险

 

 

 

AT模式

 seata AT是基于XA 事务协议演变而来,,但是seata 却不需要遵循XA数据库事务协议

(mysql xa协议 https://dev.mysql.com/doc/refman/8.0/en/xa.html)

整体提交机制

两阶段提交协议(2pc)的演变：

• 一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。
• 二阶段：

• 提交异步化，非常快速地完成。
• 回滚通过一阶段的回滚日志进行反向补偿。

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

在第一阶段和第二阶段均由seata 框架处理记录,开发人员不需要关注事务,只需贴@GlobalTransactional注解

一阶段：

在一阶段，Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数据，在业务数据被更新前，将其保存成“before image”，然后执行“业务 SQL”更新业务数据，在业务数据更新之后，再将其保存成“after image”，最后生成行锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。

 

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

 

 

二阶段回滚：

二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。回滚方式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 “after image”，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。

 

 

seata AT模式的官方详解

https://seata.io/zh-cn/docs/overview/what-is-seata.html

 

 

TCC事务

什么是TCC

TCC 是分布式事务中的二阶段提交协议，它的全称为 Try-Confirm-Cancel，即资源预留（Try）、确认操作（Confirm）、取消操作（Cancel），他们的具体含义如下：

1. Try：对业务资源的检查并预留；
2. Confirm：对业务处理进行提交，即 commit 操作，只要 Try 成功，那么该步骤一定成功；
3. Cancel：对业务处理进行取消，即回滚操作，该步骤回对 Try 预留的资源进行释放。

TCC 是一种侵入式的分布式事务解决方案，以上三个操作都需要业务系统自行实现，对业务系统有着非常大的入侵性，设计相对复杂，但优点是 TCC 完全不依赖数据库，能够实现跨数据库、跨应用资源管理，对这些不同数据访问通

过侵入式的编码方式实现一个原子操作，更好地解决了在各种复杂业务场景下的分布式事务问题。

 

 

AT和TCC的区别

AT 模式基于 支持本地 ACID 事务 的 关系型数据库：

• 一阶段 prepare 行为：在本地事务中，一并提交业务数据更新和相应回滚日志记录。
• 二阶段 commit 行为：马上成功结束，自动 异步批量清理回滚日志。
• 二阶段 rollback 行为：通过回滚日志，自动 生成补偿操作，完成数据回滚。

相应的，TCC 模式，不依赖于底层数据资源的事务支持：

• 一阶段 prepare 行为：调用 自定义 的 prepare 逻辑。
• 二阶段 commit 行为：调用 自定义 的 commit 逻辑。
• 二阶段 rollback 行为：调用 自定义 的 rollback 逻辑。

所谓 TCC 模式，是指支持把 自定义 的分支事务纳入到全局事务的管理中

 

标签：回滚,seata,事务,业务,提交,TCC
来源： https://www.cnblogs.com/moron/p/16451837.html