目录
两阶段提交协议
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差一些，不过如果是并发量不大的系统对数据一致性要求又高可用考虑使用。