关于java:分布式事务-Seata-AT模式原理与实战

Seata 是阿里开源的基于 Java 的分布式事务解决方案

Seata 提供四种模式解决分布式事务场景，AT，XA，TCC，Saga。简略叨咕叨咕我对这几种模式的了解

AT

这是 Seata 的一大特色，AT 对业务代码齐全无侵入性，应用非常简单，革新成本低。咱们只须要关注本人的业务 SQL，Seata 会通过剖析咱们业务 SQL，反向生成回滚数据

AT 蕴含两个阶段

一阶段，所有参加事务的分支，本地事务 Commit 业务数据和回滚日志（undoLog）
二阶段，事务协调者依据所有分支的状况，决定本次全局事务是 Commit 还是 Rollback（二阶段是齐全异步）

XA

也是咱们常说的二阶段提交，XA 要求数据库自身提供对标准和协定的反对。XA 用起来的话，也是对业务代码无侵入性的。

上述其余三种模式，都是属于 弥补型，无奈保障全局一致性。啥意思呢，例如刚刚说的 AT 模式，咱们是可能读到这一次分布式事务的中间状态，而 XA 模式不会。

弥补型事务处理机制构建在事务资源（数据库）之上（要么在中间件层面，要么在利用层面），事务资源自身对分布式事务是无感知的，这也就导致了弥补型事务无奈做到真正的全局一致性。
比方，一条库存记录，处在弥补型事务处理过程中，由 100 扣减为 50。此时，仓库管理员连贯数据库，查问统计库存，就看到以后的 50。之后，事务因为意外回滚，库存会被弥补回滚为 100。显然，仓库管理员查问统计到的 50 就是脏数据。
如果是 XA 的话，两头态数据库存 50 由数据库自身保障，不会被仓库管理员读到（当然隔离级别须要读已提交以上）

然而全局一致性带来的后果就是 数据的锁定（AT 模式也是存在全局锁的，然而隔离级别无奈保障，后边咱们会具体说），例如全局事务中有一条 update 语句，其余事务想要更新同一条数据的话，只能期待全局事务完结

传统 XA 模式是存在一些问题的，Seata 也是做了相干的优化，更多对于 Seata XA 的内容，传送门????http://seata.io/zh-cn/blog/se…

TCC

TCC 模式同样蕴含两个阶段

Try 阶段：所有参加分布式事务的分支，对业务资源进行检查和预留
二阶段 Confirm：所有分支的 Try 全副胜利后，执行业务提交
二阶段 Cancel：勾销 Try 阶段预留的业务资源

比照 AT 或者 XA 模式来说，TCC 模式须要咱们本人形象并实现 Try，Confirm，Cancel 三个接口，编码量会大一些，然而因为事务的每一个阶段都由开发人员自行实现。而且相较于 AT 模式来说，缩小了 SQL 解析的过程，也没有全局锁的限度，所以 TCC 模式的性能是优于 AT、XA 模式。
PS：果然简略和高效难以两全的

Saga

Saga 是长事务解决方案，每个参与者须要实现事务的 正向操作和弥补操作。当参与者正向操作执行失败时，回滚本地事务的同时，会调用上一阶段的弥补操作，在业务失败时最终会使事务回到初始状态

Saga 与 TCC 相似，同样没有全局锁。因为相比短少锁定资源这一步，在某些适宜的场景，Saga 要比 TCC 实现起来更简略。
因为 Saga 和 TCC 都须要咱们手动编码实现，所以在开发时咱们须要参考一些设计上的标准，因为不是本文重点，这里就不多说了，能够参考分布式事务 Seata 及其三种模式详解

在咱们理解完四种分布式事务的原理之后，咱们回到本文重点 AT 模式

模仿需要：以下订单为例，在分布式的电商场景中，订单服务和库存服务可能是两个数据库

咱们先来看看 AT 模式下的代码是什么样的，这里疏忽了 Seata 的相干配置，只看业务局部

在须要开启分布式事务的办法上标记 @GlobalTransactional，而后执行别离执行扣减库存和扣减库存操作的，事务的参与者能够是本地的数据源，或者 RPC 的近程调用（近程调用的话须要携带全局事务 ID，也就是上图的 xid）

之前说过 AT 模式分为两个阶段，第一阶段包含提交业务数据和回滚日志（undoLog），第一阶段具体流程如下图

GlobalTransactional 切面

标记 @GlobalTransactional 的办法通过 AOP 实现了，开启全局事务和提交全局事务两个操作，与 Spring 事务机制相似，当 GlobalTransactionalInterceptor 在事务执行过程中捕捉到 Throwable 时，会发动全局事务回滚

0.1 步骤中会生成一个全局事务 ID

0.2 所有事务参与者执行完结后，一阶段事务提交

undoLog

咱们先来看看 Seata undoLog 的构造

// 省略了相干办法
public class SQLUndoLog {
    // insert, update ...
    private SQLType sqlType;

    private String tableName;

    private TableRecords beforeImage;

    private TableRecords afterImage;
}

Seata 在执行业务 SQL 前后，会生成 beforeImage 和 afterImage，在须要回滚时，依据 SQLType，决定具体的回滚策略，例如 SQLType=update 时，将数据回滚到 beforeImage 的状态，如果 SQLType=insert，则依据 afterImage 删除数据

如 2.4 所示，每条业务 SQL，执行胜利后，会为这条 SQL 生成 LockKey，格局为tableName:PrimaryKey

注册分支事务

在 3.1 步骤注册分支事务时，client 会把所有的 LockKey 拼到一起作为 全局锁 发送给 Seata-server。如果注册胜利，写入 undoLog，并提交本地事务，一阶段完结，期待二阶段反馈

如果以后有其余分支事务曾经持有了雷同的锁（即其余事务也在解决雷同表的同一行），则 client 注册事务分支失败。client 会依据客户端定义的重发工夫和重发次数进行一直的尝试，如果重试完结依然没有取得锁，则一阶段失败，本地事务回滚。如果该全局事务存在曾经注册胜利分支事务，Seata-server 进行二阶段回滚

全局锁会在分支事务二阶段完结后开释

Seata 全局锁的设计是为了什么？
以扣减库存场景为例，TX1 实现库存扣减的一阶段，库存从 100 扣减为 99，正在期待二阶段的告诉。TX2 也要扣减同一商品的库存，如果没有全局锁的限度，TX2 库存从 99 扣减为 98，这时如果 TX1 接管到回滚告诉，进行回滚把库存从 98 回滚到 100。因为没有全局锁，造成了脏写

二阶段是齐全异步化的并且齐全由 Seata 管制，Seata 依据所有事务参与者的提交状况决定二阶段如何解决

如果所有事务提交胜利，则二阶段的工作就是删除一阶段生成的 undoLog，并开释 全局锁
如果局部事务参与者提交失败，则须要依据 undoLog 对曾经注册的事务分支进行回滚，并开释 全局锁

至此咱们曾经初步理解了 Seata 的 AT 模式是如何实现的了

如果你也和我一样，认真思考了上述过程，可能会提出一些问题，这边我列举一下我在学习 Seata 时，遇到的问题，以及我得出的论断

问题 1. Seata 如何做到无侵入的剖析业务 SQL 生成 undoLog，注册事务分支等操作？

Seata 代理了 DataSource，咱们能够通过在代码注入一个 DataSource 来验证我的说法，目前的 DataSource 是 io.seata.rm.datasource.DataSourceProxy

所有的 Java 长久化框架，最终在操作数据库时都会通过 DataSource 接口获取 Connection，通过 Connection 实现对数据库的增删改查，事务管制。

Seata 通过代理 Connection 的形式，做到了无侵入的生成 undoLog，注册事务分支，具体源码能够查看io.seata.rm.datasource.ConnectionProxy

问题 2. ConnectionProxy 如何判断以后事务是全局事务，还是本地事务？

通过以后线程是否绑定了全局事务 id，在进行全局事务之前，须要调用RootContext.bind(xid);

问题 3. 全局事务并发更新

还是以下订单扣减库存的场景为例，如果 TX1 和 TX2 同时扣减 product_id 为 1 的库存，这时 Seata 会不会生成雷同的 beforeImage？

举个例子，TX1 读库存为 100，TX1 扣减库存 1，此时 BeforeImage 为 100
紧接着如果 TX2 读库存也为 100，那么就有问题了，不论 TX2 扣减多少库存，如果 TX1 回滚那么相当于笼罩了 TX2 扣减的库存，呈现了脏写

Seata 是如何解决这个问题的？

源码地位：io.seata.rm.datasource.exec.AbstractDMLBaseExecutor::executeAutoCommitFalse

能够看到这里的逻辑和我下面画的图统一，证实我没有瞎说 ????

咱们来看一下 beforeImage()，这是一个形象办法，看一下他的子类UpdateExecutor 是如何实现的

通过 Debug，能够看出 Seata 这边也是的确思考了这个问题，间接简略而无效的解决了这个问题

回到咱们的例子，因为 SELECT FOR UPDATE 的存在，TX2 如果也想读同一条数据的话，只能等到 TX1 提交事务后，能力读到。所以问题解决

问题 4. 全局事务外的更新

咱们当初能够确认在 Seata 的保障下，全局事务，不会造成数据的脏写，然而全局事务外会！

什么意思呢？

还以库存为例

用户正在抢购，用户 A 实现了 1 阶段的库存扣减，这个时候库存为 99。
此时库存管理员上线了，他查了一下库存为 99。嗯 … 太少了，我加 100 个，库存管理员把库存更新为 200。
而此时 seata 给用户 A 生成 beforeImage 为 100，如果此时用户 A 的全局事务失败了，产生了回滚，再次将库存更新为 100… 再次出现脏写

Seata 针对这个问题，提供了 @GlobalLock 注解，标记该注解时，会像全局事务一样进行 SQL 剖析，竞争全局锁，就不会呈现上述问题了

对于这个问题能够参考 Seata 的 FAQ 文档 http://seata.io/zh-cn/docs/ov…

问题 5. @GlobalTransactional 和 @Transactional 同时应用会怎么样

咱们上文中曾经说过了 @GlobalTransactional 的作用了，他是负责开启全局事务 / 提交事务 1 阶段，说白了 @GlobalTransactional 只和 Seata-server 交互，而 @Transactional 治理的是本地数据库的事务，所以二者不发生冲突。

然而须要留神 @GlobalTransactional AOP 覆盖范围肯定要大于 @Transactional

问题 6. 如果其中某一个事务分支超时未提交，会产生什么

这个我并没有看源码，而是通过跑 demo，验证的

例如当初有 A，B 两个事务分支

A 失常提交，并向 Seata 注册分支胜利
B 2 分钟后提交事务，并向 Seata 发动注册

Seata 的全局事务超时工夫，默认是 1 分钟，Seata-server 在检测到有超时的全局事务时，会向所有已提交的分支，发动回滚。而超时提交的事务，向 Seata-server 发动分支注册时，响应后果为事务已超时，或者事务不存在，也会回滚本地事务

问题 7. Seata-client 如何接管 Seata-server 发动的告诉

Seata-client 蕴含了 Netty 服务，在启动时 Netty 会监听端口，并向 Seata-server 发动注册。server 中存储了 client 的调用地址。

咱们学习了 Seata 的 AT 模式是如何工作的，能够看出 Seata 模式在开发上是非常简单的，然而 Seata 的背地为了维持分布式事务的数据一致性，做了大量的工作，AT 模式非常适合现有的业务模型间接迁徙。

然而他的毛病也很显著，性能并不是那么的优良。例如咱们刚刚看到的全局锁的问题，为了数据不会产生脏写，Seata 就义了业务的并发能力。在十分要求性能的场景，可能还是须要思考 TCC，SAGA，可靠消息等计划

在应用 Seata 开发前，倡议大家先去浏览一下 FAQ 文档，防止踩坑 https://seata.io/zh-cn/docs/o…

https://github.com/TavenYin/t…

Seata 是什么 – http://seata.io/zh-cn/docs/overview/what-is-seata.html
Seata 常见问题 – http://seata.io/zh-cn/docs/overview/faq.html
分布式事务中间件 Seata 的设计原理 – http://seata.io/zh-cn/blog/seata-at-mode-design.html
分布式事务 Seata 及其三种模式详解 – http://seata.io/zh-cn/blog/seata-at-tcc-saga.html
分布式事务如何实现？深刻解读 Seata 的 XA 模式 – http://seata.io/zh-cn/blog/seata-xa-introduce.html

关于java:分布式事务-Seata-AT模式原理与实战

AT，XA，TCC，Saga

AT

XA

TCC

Saga

AT 如何应用

AT 一阶段

GlobalTransactional 切面

undoLog

注册分支事务

AT 二阶段

对 Seata 提出的疑难

总结

DEMO

参考

Just My Socks（注册教程内含优惠码）

关于java:分布式事务-Seata-AT模式原理与实战

AT，XA，TCC，Saga

AT

XA

TCC

Saga

AT 如何应用

AT 一阶段

GlobalTransactional 切面

undoLog

注册分支事务

AT 二阶段

对 Seata 提出的疑难

总结

DEMO

参考

Just My Socks（注册教程 内含优惠码）

Just My Socks（注册教程内含优惠码）