Seata之AT模式

目录

AT模式的引进

AT模式前提

AT模式的工作流程

案例流程梳理

AT模式的原理

具体使用

优缺点

小结 


AT模式的引进

我们XA模式有死锁(协议阻塞)问题:XA prepare 后,分支事务进入阻塞阶段,收到 XA commit 或 XA rollback 前必须阻塞等待。如果没有一个靠谱的协调者存在,比如abc三个库的数据被二阶段决议为提交,此时ab收到的指令,提交后,c库在收到指令后挂了,并没有提交xa事务,或者协调者没有做到二阶段重试,那么这个没有提交的xa事务将会一直 持有锁,造成死锁的局面。在这里我们将会引进AT模式,解决同步阻塞等问题。

seata的AT模式是一个无侵入的分布式事务。

AT模式前提

  • 基于支持本地 ACID 事务的关系型数据库。
  • Java 应用,通过 JDBC 访问数据库。

AT模式的工作流程

AT模式是基于一个全局的事务管理器来管理的。例如,在全局事务下,当我们存在A,B两个服务的时候,A和B的提交都会生成一个undo_log的记录,会记录下执行前和执行后的镜像,如果一段提交没有错误的话,则会进行二段提交,如果在全局事务中有异常抛出,则根据undo_log进行回滚。

 Seata之AT模式_第1张图片

阶段一RM的工作:

  • 注册分支事务

  • 记录undo-log(数据快照)

  • 执行业务sql并提交

  • 报告事务状态

阶段二提交时RM的工作:

  • 删除undo-log即可

阶段二回滚时RM的工作:

  • 根据undo-log恢复数据到更新前

案例流程梳理

我们用一个真实的业务来梳理下AT模式的原理。

比如,现在又一个数据库表,记录用户余额:

id money
1 100

 其中一个分支业务要执行的SQL为:

update tb_account set money = money - 10 where id = 1 

Seata之AT模式_第2张图片

AT模式下,当前分支事务执行流程如下:

一阶段:

(1)TM发起并注册全局事务到TC

(2)TM调用分支事务

(3)分支事务准备执行业务SQL

(4)RM拦截业务SQL,根据where条件查询原始数据,形成快照。

Seata之AT模式_第3张图片

(6)RM执行业务SQL,提交本地事务,释放数据库锁。此时 money = 90 

(7)RM报告本地事务状态给TC

二阶段:

(1)TM通知TC事务结束

(2)TC检查分支事务状态

(a)如果都成功,则立即删除快照

Seata之AT模式_第4张图片

(b)如果有分支事务失败,需要回滚。读取快照数据({"id": 1, "money": 100}),将快照恢复到数据库。此时数据库再次恢复为100

Seata之AT模式_第5张图片

AT模式的原理

  • 事务的发起者开始一个全局事务,并在本地事务管理器中开始一个本地事务。
  • 事务的发起者调用其他参与者的服务,将全局事务ID传递给它们。
  • 参与者接收到全局事务ID后,在本地事务管理器中开始一个本地事务,并执行操作。
  • 当参与者的本地事务执行成功时,将操作结果记录在本地日志中。
  • 事务的发起者完成所有参与者的服务调用后,调用各个参与者的提交接口。
  • 参与者检查本地事务的日志记录,如果操作都成功,则提交本地事务;否则,回滚本地事务。

具体使用

 修改application.yml文件(每个参与事务的微服务),开启XA模式:

seata:
  data-source-proxy-mode: AT

给发起全局事务的入口方法添加@GlobalTransactional注解:  

    @GlobalTransactional
    @Transactional(rollbackFor = Exception.class)
    public void saveOrder(OrderSaveParam orderSaveParam) {
        // 参数校验等必要操作
        // ...

        // 修改库存
        reduceGoodsCount(goodsCountMap);

        // 扣除余额
        reduceMoney(id,money);


        // 异常回滚事务
        int i = 1 / 0;
    }

优缺点

优点

  • 较高的性能:AT模式在每个参与者的本地事务中执行操作,避免了全局锁和阻塞的问题,提高了系统的并发性能。

  • 简化的实现:相对于XA模式,AT模式的实现相对简单,不需要涉及全局事务协调器,减少了开发和维护的复杂性。

  • 本地事务的独立性:每个参与者在本地事务管理器中管理自己的事务,可以独立控制和优化本地事务的执行。

缺点

  • 弱一致性:AT模式对一致性的要求相对较低,可能会出现数据不一致的情况。在某些场景下,可能需要更高的一致性保证,需要考虑其他分布式事务处理模式。

  • 隔离级别限制:由于AT模式依赖于本地事务的隔离性,参与者的隔离级别受限于本地事务管理器支持的隔离级别,可能无法满足某些特定的隔离需求。

  • 容错性和恢复性:AT模式在发生故障或错误时,需要考虑如何处理事务的回滚和恢复,以确保数据的一致性和可靠性。

小结 

性能:高

模式:AP,存在数据不一致的中间状态

难易程度:简单,靠SEATA自己解析反向SQL并闻滚

使用要求

  • 所有服务与数据库必须要自己拥有管理权,因为要创建UNDO LOG表

应用场景

  • 高并发互联网应用,允许数据出现短时不一致,可通过对账程序或补录来保证最终一致性。

你可能感兴趣的:(SpringCloud体系解读,数据库,开发语言,java,分布式,springboot,springcloud)