分布式事务-seata-AT使用详解

目录

两阶段提交协议

seata-AT模式

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

 seata-AT 专业术语

 实操seata-AT

前提准备

TM与TCC-RM的搭建

 seata服务端的搭建

TM的搭建

实战效果

 总结：

---

上一篇文章简单的对分布式事务进行了简单的介绍，本篇文章则对分布式事务seata-AT进行使用详解。

由前一篇文章的分布式事务架构图，我们知道seata-AT其实是基于2pc架构的，是数据强一致性的框架。

那我们来看一下什么是2pc。这里引用seata官网的一篇博客

两阶段提交协议

两阶段提交协议：事务管理器分两个阶段来协调资源管理器，第一阶段准备资源，也就是预留事务所需的资源，如果每个资源管理器都资源预留成功，则进行第二阶段资源提交，否则协调资源管理器回滚资源。

注释：这里我们资源管理器其实就是支持ACID事务的关系型数据库

seata-AT模式

Seata 开源了 AT 模式。AT 模式是一种无侵入的分布式事务解决方案。在 AT 模式下，用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作。

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

• 一阶段：

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

• 二阶段提交：

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

 

• 二阶段回滚：

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

 seata-AT 专业术语

 

TC (Transaction Coordinator) - 事务协调者

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

TM (Transaction Manager) - 事务管理器

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

RM (Resource Manager) - 资源管理器

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

 实操seata-AT

参考官网的springcloud集成seata-AT博客

前提准备

• 注册中心 nacos
• seata服务端(TC）

TM与TCC-RM的搭建

基于Spring Cloud + Feign的TCC和AT的实现，项目的搭建直接看源码(本工程提供了AT模式与TCC模式的DEMO)

DEMO工程源码

 

seata服务端的搭建

服务端搭建文档

TM的搭建

service-tm

实战效果

当我们把注册中心搭建好，seata的服务端TC搭建好后，我们下载源码demo，可以发现有三个服务，service-tm、service-tcc、service-at。service-tcc本篇文章不做解析，后面再详解，我们依次启动service-tm和service-at。源码图如下。

 我们看service层调用at服务的代码如下：其实代码非常非常简单，就在我们的业务方法上面加了一个@GlobalTransactional(timeoutMills = 60000 * 4) 注解，代表启动了seata-at模式。

1.当我们的at服务报异常或者超时获取其它原因，我们的tm服务会和at服务一起进行回滚，达到数据一致性。

2.当我们的tm服务抛异常或者其它什么原因，我们的at服务照样回滚，达到数据一致性。实在是太好用，但是因为它的底层原理是一直拿着数据的行锁，性能比tcc要差许多。

 总结：

本文讲了2pc数据强一致性的分布式事务框架seata-tcc的基本原理和实操。简单好用就是性能比tcc差一些，不过如果是并发量不大的系统对数据一致性要求又高可用考虑使用。