另一方面，前言SeATa是一种开源分布式事务解决方案，star达到18100，社区活跃程度极高，希望在微服务框架下提供高性能、简单易用的分布式事务服务交付本文分析了Seata-AT的实现原理，使用户对at模式有更深入的认识。
二、Seata事务模式是什么？ 1. Seata事务的定义Seata定义了全局事务的框架。 全局事务被定义为几个分支事务的整体协调。
TM请求TC启动全局事务(Begin )、提交(Commit )、回滚(Rollback )。 TM将表示全局事务的XID绑定到分支事务。 RM在TC中注册，并将分支事务与代表XID的全局事务相关联。 RM向TC报告分支事务的执行结果。 (可选) TC向RM发送分支提交或分支回滚命令。
Seata的全局事务处理流程分为两个阶段：
运行执行阶段 ：分支事务，确保执行结果是可回滚的和持久的。 基于完成阶段：执行阶段的结果形成的决议将通过TM发出的全局提交或回滚请求应用于TC，TC命令RM驱动分支事务进行提交或回滚
Seata的所谓事务模式是指在Seata全局事务框架下执行的分支事务的操作模式。 准确地说，分支事务模式
不同的事务模式的区别在于分支事务以不同的方式实现全局事务的两个阶段的目标。 也就是说，回答以下两个问题：
如何执行和保证执行阶段 ：执行结果可回滚(可回滚)和持久？ 收到33558www.Sina.com/TC的命令后，回滚/提交事务
2 .其他两级事务如何在Seata事务框架下运行1 ) TCC事务模式首先，我们来看看TCC事务如何融入Seata事务框架。
实际上，你会发现它非常类似于Seata的事务框架图。 RM负责管理的是一级try运行和两级confirm/cancel。 同样，TM将启动事务，在RM调用到TM后执行一步try方法，并等待调用链接结束，然后TM将两步决议通知TC。 此时，TC
2 ) XA事务模式
如图所示，XA模式实际上是Seata基础使用XA接口，并在一个阶段两个阶段自动处理。 在一个阶段，XA的RM通过代理用户数据源创建XA连接，打开XA事务(XA start )和XA-prepare ) )，此时XA的任何操作都是永久的，达
三、AT模式是什么？ 我们先来看看例子。
1 .一阶段3358 www.Sina.com/http://www.Sina.com /。
用户看不到一个阶段的运行流程，用户端的业务sql保持不变，但在AT模式的下一阶段具体发生了什么？ 接下来，简单地说一下吧。
分析sql并搜索上一个镜像。 运行完成阶段：业务sql。 查询执行后的数据作为后视镜，提交业务 sql：2 .二级：删除事务相关信息即可(理论上不删除也没问题)。
回滚：取出前面的镜像回滚。
在上面的简单例子中，实际上，AT模式是自动补偿式事务，AT具体在做什么呢？ 稍后说明。
四、AT如何保证分布式事务的一致性？update product set name = 'GTS' where name = 'TXC'
刚看到上图可能会有很多人产生疑问，其实这就是无创AT模式的做法给人的印象。 首先，用户还是从界面进入，到达事务启动器。 在这种情况下，对于业务开发人员来说，该启动器门户是一个业务接口，它以相同的方式运行业务sql，并且return以相同的方式将信息响应到客户端。 后面是用户的sql托管在Seata代理上，Seata-AT模式可感知和操作用户的所有sql，确保一致性。
select id, name, since from product where name = 'TXC'
如图所示，当APP应用程序启动时，Seata会自动代理用户的数据源。 熟悉JDBC操作的用户其实对DataSource很熟悉。 拿到DataSource后，您就掌握了数据源连接，也可以在后面找到
做些“小动作”，此时对用户来讲也是无感知无入侵。之后业务有请求进来，执行业务 sql 时，Seata 会解析用户的 sql，提取出表元数据，生成前镜像，再通过执行业务 sql，保存执行 sql 后的后镜像（至于后镜像的介绍之后会讲到），生成行锁之后在注册分支时携带到 Seata-Server，也就是 TC 端。
到此为止，在 Client 端的一阶段操作就已经完成了，无感知、无入侵。此时如果思考下，会发现这里其实有一个行锁，这个行锁是干什么用的呢？这就是要接着讲到 Seata-AT 是如何保证分布式下的事务隔离性，这里直接拿官网的示例来说。
1. 写隔离 一阶段本地事务提交前，需要确保先拿到全局锁 。拿不到全局锁，不能提交本地事务。拿全局锁的尝试被限制在一定范围内，超出范围将放弃，并回滚本地事务，释放本地锁。以一个示例来说明：
两个全局事务 tx1 和 tx2，分别对 a 表的 m 字段进行更新操作，m 的初始值 1000。
tx1 先开始，开启本地事务，拿到本地锁，更新操作 m = 1000 - 100 = 900。本地事务提交前，先拿到该记录的全局锁，本地提交释放本地锁。tx2 后开始，开启本地事务，拿到本地锁，更新操作 m = 900 - 100 = 800。本地事务提交前，尝试拿该记录的全局锁，tx1 全局提交前，该记录的全局锁被 tx1 持有，tx2 需要重试等待全局锁 。
tx1 二阶段全局提交，释放全局锁 。tx2 拿到全局锁提交本地事务。
如果 tx1 的二阶段全局回滚，则 tx1 需要重新获取该数据的本地锁，进行反向补偿的更新操作，实现分支的回滚。
此时如果 tx2 仍在等待该数据的全局锁，同时持有本地锁，则 tx1 的分支回滚会失败。分支的回滚会一直重试，直到 tx2 的全局锁等锁超时，放弃全局锁并回滚本地事务释放本地锁，tx1 的分支回滚最终成功。
因为整个过程全局锁在 tx1 结束前一直是被 tx1 持有的，所以不会发生脏写的问题。
这个时候隔离性想必大家已经比较明白了，此时一阶段的大部分操作相信大家也比较明白了，接下来我们继续往下一阶段解析。
2. AT 模式二阶段处理
由上图可见，在二阶段提交时，TC 仅是下发一个通知 ：把之前一阶段做记录的 undoLog 删除，并把相关事务信息如：行锁删除，之后让因为在竞争锁被阻塞的事务顺利进行。
而二阶段是回滚时，则要多做一些处理。
首先在 Client 端收到 TC 告知的二阶段是回滚时，会去查到对应的事务的 undolog，取出后镜像，对比当前的数据（因为 SeataAT 是从业务应用层面进行保护分布式事务，如果此时在数据库层面直接修改了库内信息，这个时候 SeataAT 的行锁不起隔离性作用），如果出现了在全局事务以外的数据修改，此时判定为脏写，而 Seata 因为无法感知这个脏写如何发生，此时只能打印日志和触发异常通知，告知用户需要人工介入（规范修改数据入口可避免脏写）。
而如果没有发生脏写就比较简单了，拿出前镜像，众所皆知事务是需要有原子性的，要么一起发生，要么都不发生，此时前镜像记录了发生之前的数据，进行回滚后，就达到了类似本地事务那样的原子性效果。回滚后，再把事务相关信息，如 undolog，行锁进行删除。二阶段回滚算是告一段落了。
既然介绍完了 AT 模式的一阶段及二阶段的原理思想方式，那么 AT 在 Seata 的分布式事务框架下是怎么样的呢?
可以看到，AT 与其它事务模式在 Seata 事务框架中，会多出一个 undolog 的表（相对其它模式的入侵点），但是除此之外，对业务来说，几乎是零入侵性，这也就是为什么 AT 模式在 Seata 中受众广泛的原因。
首先应该明白，目前为止，不存在有任何一种分布式事务的可以满足所有场景。
无论 AT 模式、TCC 模式还是 Saga 模式，这些模式的提出，本质上都源自 XA 规范对某些场景需求的无法满足。
目前分为 3 点来做出对比：
数据锁定AT 模式使用全局锁保障基本的写隔离，实际上也是锁定数据的，只不过锁在 TC 侧集中管理，解锁效率高且没有阻塞的问题。
TCC 模式无锁，利用本地事务排他锁特性，可预留资源，在全局事务决议后执行相应操作。
XA 模式在整个事务处理过程结束前，涉及数据都被锁定，读写都按隔离级别的定义约束起来。
死锁（协议阻塞）XA 模式 prepare 后（老版本的数据库中，需要 XA END 后，再下发 prepare <三阶段由来>)，分支事务进入阻塞阶段，收到 XA commit 或 XA rollback 前必须阻塞等待。
AT 可支持降级，因为锁存储在 TC 侧，如果 Seata 出现 bug 或者其它问题，可直接降级，对后续业务调用链无任何影响。
TCC 无此问题。
性能性能的损耗主要来自两个方面：一方面，事务相关处理和协调过程，增加单个事务的 RT；另一方面，并发事务数据的锁冲突，降低吞吐。其实主要原因就是上面的协议阻塞跟数据锁定造成。
XA 模式它的一阶段不提交，在大并发场景由于锁存储在多个资源方（数据库等），加剧了性能耗损。
AT 模式锁粒度细至行级（需要主键），且所有事务锁存储在 TC 侧，解锁高效迅速。
TCC 模式性能最优，仅需些许 RPC 开销，及 2 次本地事务的性能开销，但是需要符合资源预留场景，且是对业务侵入性较大（需要业务开发者每个接口分为 3 个，一个 try，2 个二阶段使用的 confirm 和 cancel ）。
可能很多同学对 XA 和 AT 的锁 & 协议阻塞不是特别理解，那么直接来看下图：
可以试着猜一下是哪个是 XA？其实下图的是 XA，因为它带来的锁粒度更大，且锁定时间更久，导致了并发性能相对 AT 事务模型来说，差的比较多，所以至今XA模式的普及度都不很太高。
首先控制台是 Seata 用户暴露已久的一个问题，没有一个可视化界面，使得用户对 Seata 的可靠性出现了怀疑，更由于没有控制台，局限了很多在 Seata 上可人工介入分布式事务的可能性等问题，所以未来在 1.5.0 的版本会带来控制台的加入，也欢迎更多的同学加入进来一起共建!
Raft 集成Raft 集成的原因，可能大部分用户不是特别知晓，首先要知道目前 TC 端的事务信息都是存储在外部存储器，比如数据库、redis、mongodb(PR 阶段)，这就造成了如果外部存储宕机，Seata-Server 集群的完全不可用。即便 Server 是集群部署，有 10 个甚至更多节点，都会因此而不可用，这是不可接受的。
所以引入 Raft 来让每个 Seata-Server 的事务信息达到一致，即便某个节点宕机，也不会破坏事务信息准确性，从而也让分布式事务的一致性得到了更好的保证。（关于 Seata-Server raft 的实现之后会以新篇章来分享。）
undoLog 压缩这个是 1.5.0 AT 模式比较大的性能优化，由于一阶段操作的数据多且大，因为 Seata 在背后为用户插入了 undolog 信息，由此可能也会变得大，有造成了入库缓慢的可能，所以要把 undolog 进行压缩，使 undolog 的插入不再成为 AT 事务在分支数据量大的时候成为一个大的心梗开销。
六、总结AT 说到底就是实现对资源操作的代理，并记录原先 & 变更后的状态，并用锁保证该数据的隔离性。在调用链中出现异常时，还原所有分支数据，达到分布式事务下的“原子性”。
未来呢？redis,mongodb,mq? 尽情期待。
Seata 项目的最核心的价值在于：构建一个全面解决分布式事务问题的标准化平台。
基于 Seata，上层应用架构可以根据实际场景的需求，灵活选择合适的分布式事务解决方案，非常欢迎大家参与到项目的建设中，共同打造一个标准化的分布式事务平台。
七、参考原文： https://mp.weixin.qq.com/s/WAaqOf9HBCf3CJs-S_KMUg