分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第1张图片

前言

事务(TRANSACTION)是一个不可分割的逻辑单元,包含了一组数据库操作命令,并且把所有的命令作为一个整体向系统提交,要么都执行、要么都不执行。

事务作为系统中必须考虑的问题,无论是在单体项目还是在分布式项目中都需要进行处理,而尤其在分布式微服务调用的情况下,事务的处理就变得复杂。

本篇博客进行了Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比,阐述了三种模式的联系和不同,并结合案例分析了seata的作用,对比了XA模式和AT模式下对执行其他操作的影响。

本篇博客源码以及seata1.4版本的安装包见下面git地址
https://gitee.com/pet365/seta-demo

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第2张图片

关于分布式事务,CAP理论见下面博客:

分布式事务——CAP理论 & 解决分布式事务的思路 & Seata组件初识 和 部署

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第3张图片
SpringCloud其他相关的组件博客文章合集如下:

【合集】Spring Cloud 组件——架构进化史话 & Eureka,Nacos,OpenFeign,Ribbon,Sentinel,Gateway . . .

在这里插入图片描述

目录

  • 前言
  • 引出
  • Seata分布式事务XA模式
    • 一、Java中分布式事务解决方案JTA
      • 1、什么是XA
      • 2、Java分布式事务的解决方案JTA(Java Transaction API)
    • 二、Seata XA模式
      • 1、执行阶段
      • 2、完成阶段
      • 3、XA模式的优缺点
      • 4、XA模式的思考
  • Seata分布式事务AT模式
    • 一、AT模式介绍
      • 1、AT摸式的原理
      • 2、执行流程
    • 二、AT模式的开发
      • 1、修改配置,准备undo_log表
      • 2、AT模式与XA模式
  • Seata分布式事务TCC模式
    • 一、TCC模式介绍
    • 二、案例分析
      • 1、Try阶段
      • 2、Confirm阶段
      • 3、Cancel阶段
  • 结合代码对比AT模式和XA模式
    • 开启全局事务AT模式
      • 1.超时导致的回滚+日志分析
      • 2.账户余额不足导致回滚
    • 如果未开启全局事务
    • 执行期间操作对比
      • AT模式
      • XA模式
  • 附录:
    • 1、账户account的SQL
    • 2、订单Order的SQL
    • 3、库存Storage的SQL
  • 总结

引出


1、XA规范使用两阶段提交(2PC,Two-Phase Commit)来保证所有资源同时提交或回滚任何特定的事务。

  • 第一阶段为准备(prepare)阶段。即所有的参与者准备执行事务并锁住需要的资源。参与者ready时,向transaction manager报告已准备就绪。
  • 第二阶段为提交阶段(commit)。当transaction manager确认所有参与者都ready)后,向所有参与者发送commit命令。

2、AT模式与XA模式

(1)Seata AT模式是两阶段提交协议的演变:

  • 一阶段:业务数据和回滚日志记录在同一个本地事务中提交,释放本地锁和连接资源。
  • 二阶段:
    • 提交异步化,非常快速地完成。
    • 回滚通过一阶段的回滚日志进行反向补偿。

(2)AT模式与XA模式的区别

  • XA模式一阶段不提交事务,锁定资源;AT模式一阶段直接提交,不锁定资源。
  • XA模式依赖数据库机制实现回滚:AT模式利用数据快照实现数据回滚。
  • XA是强一致性;AT是最终一致性。

3、Tny-Confirm-Cancel,TCC模式

TCC是分布式事务中二阶段提交协议的实现,它的全称为Tny-Confirm-Cancel,即资源预留(Try)、确认操作(Confirm)、取消操作(Cancel),具体含义如下:

  • Try(prepare)阶段:对业务资源的检查并预留。
  • Confirm(commit)阶段:对y业务处理进行提交,该步骤会对Ty预留的资源进行释放,只要Try成功,Confirm-一定要能成功.
  • Cancel(rollback)阶段:对业务处理进行取消,即回滚操作。

Seata分布式事务XA模式

一、Java中分布式事务解决方案JTA

1、什么是XA

  • XA规范是X/Open组织定义的分布式事务处理(DTP,Distributed Transaction Processing)标准。
  • XA规范使用两阶段提交(2PC,Two-Phase Commit)来保证所有资源同时提交或回滚任何特定的事务。
  • 第一阶段为准备(prepare)阶段。即所有的参与者准备执行事务并锁住需要的资源。参与者ready时,向transaction manager报告已准备就绪。
  • 第二阶段为提交阶段(commit)。当transaction manager确认所有参与者都ready)后,向所有参与者发送commit命令。

XA规范在上世纪90年代初就被提出。目前,几乎所有主流的数据库都对XA规范提供了支持。

2、Java分布式事务的解决方案JTA(Java Transaction API)

定义了Java的XA接口,由具体的厂商提供实现,J2EE容器(WebLogic、JBoss)是JTA接口的实现者。

JTA的缺点:

  • 同步阻塞,并发效率差,准备阶段的成本持久,全局事务状态的成本持久。
  • 分布式架构存在瓶颈,单点的协调者(J2EE容器)会成为系统的瓶颈,需要建立协调者的集群来解决。
  • 数据源的类型受限,基本都是MySQL、Oracle类型的关系型数据库。

优点:开发代价小,程序不需要有太多的变化。

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第4张图片

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第5张图片

二、Seata XA模式

http://seata.io/zh-cn/index.html

在Seata定义的分布式事务框架内,利用事务资源(数据库、消息服务等)对XA协议的支持,以XA协议的机制来管理分支事务的一种事务模式。

XA模式需要事务资源(数据库、消息服务等)支持XA协议,比如mysql把redolog分为两个阶段。

1、执行阶段

RM一阶段的工作,XA start/XA end/XA prepare+SQL+注册分支

  • 注册分支事务到TC

    • XA Start,Seata全局事务的XID和Branchld关联起来,以便由TC 驱动 XA 分支的提交或回滚
  • 执行分支事务但不提交

    • 业务SQL操作放在XA分支中进行,由资源对XA协议的支持来保证可回滚
    • XA分支完成后,执行XA prepare,同样,由资源对XA协议的支持来保证持久化(即,之后任何意外都不会造成无法回滚的情况)
  • 报告执行状态到TC

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第6张图片

2、完成阶段

  • TC二阶段的工作,TC检测各个分支事的执行状态,如果全部成功,通知所有M提交事务;如果有失败,通知所有RM回滚事务。
  • RM二阶段的工作,接收TC指令,提交或回滚事务
    • 分支提交:执行XA分支的commit
    • 分支回滚:执行分支的rollback

3、XA模式的优缺点

(1)优点

  • 事务的强一致性,,满足ACID原则
  • 常用的数据都支持,实现简单,没有代码入侵

(2)缺点

  • 一阶段要锁定数据库资源,等待二阶段结束才释放,性能较差
  • 依赖关系型数据库实现事务

4、XA模式的思考

XA模式下默认的事务的超时时间为60000毫秒,分支事务超时后会进行全局回滚。

但是如果协调者宕机,那么其中已经准备但未提交事务的所有参与者都会被阻塞。被阻塞的根本是

例如在读已提交隔离级别上,数据库事务通常会获取到待修改行数据的行级排他锁来防止脏写。在分布式事务提交或中止前,参与者数据库在能释放这些锁,因此协调者宕机多久,这些锁就要持有多久(在没有人为干预的情况
下)。这些锁被持有的期间,导致其他事务不能修改这些数据(根据数据库的不同,读取操作也可能被阻塞),所以这些数据相关的业务都会被阻塞,导致应用大面积的不可用,直至存疑事务被解决(提交/中止)。

理论上,如果协调者崩溃并重新启动,它应该从日志中恢复事务的状态,并解决现存的疑虑事务,但是在实际生产中,仍然会有疑虑事务的出现(可能是事务日志被破坏)。

也许你可能会考虑将相关应用的数据库服务器重启,但是在2PC正确的实现中,为了原子性的保证,重启后也必须持有存疑事务的锁。那么这样唯一的解决方案是让管理员手动提交还是回滚事务。

所以,协调者的高可用是需要我们考虑的问题。

Seata分布式事务AT模式

一、AT模式介绍

Seata AT模式同样是分阶段提交的事务模型,弥补了XA模式资源锁定周期过长的缺陷。缺点就是数据不是强一致性,因为它的数据会真实的提交到数据库的,而如果后面做分支事务有问题的话,回滚靠的是日志来实现最终一致。AT模式,是seatal的默认模式。

1、AT摸式的原理

第一阶段RM的工作:

  • 首先注册分支事务到事务协调者TC中
  • 记录一个SQL更新前的快照到undo_log日志表中
  • 执行SQL并提交数据库事务
  • 记录更新后的快照到undo_log日志表中
  • 报告事务状态

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第7张图片

第二阶段RM的工作:

  • 如果此时所有微服务都执行完,并且没有出现异常情况,事务协调者TC通知RM删除udo-log记录

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第8张图片

  • 如果此时中途有微服务出现异常情况,则TC会通知RM根据udo-log记录的对应快照恢复数据到更新前

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第9张图片

2、执行流程

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第10张图片

二、AT模式的开发

1、修改配置,准备undo_log表

AT模式只需要将配置中的data-source-proxy-mode:XA改为AT,或者是直接去除这一行配置即可。

AT模式会使用到几个数据库表:

  • 重做日志表:undo_log, 在每个业务数据库中都要创建
-- ----------------------------
-- Table structure for undo_log
-- ----------------------------
DROP TABLE IF EXISTS `undo_log`;
CREATE TABLE `undo_log`  (
  `id` bigint(0) NOT NULL AUTO_INCREMENT,
  `branch_id` bigint(0) NOT NULL,
  `xid` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
  `context` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
  `rollback_info` longblob NOT NULL,
  `log_status` int(0) NOT NULL,
  `log_created` datetime(0) NOT NULL,
  `log_modified` datetime(0) NOT NULL,
  PRIMARY KEY (`id`) USING BTREE,
  UNIQUE INDEX `ux_undo_log`(`xid`, `branch_id`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 1 CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Dynamic;

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第11张图片

  • 分支事务表:branch table,在seata的数据库中创建
  • 全局事务表:global_table,在seatal的数据库中创建
  • 全局锁表:lock table,在seata的数据库中创建

全局事务表跟分支事务表是一对多的关系,一个全局事务对应多个分支事务。

2、AT模式与XA模式

(1)Seata AT模式是两阶段提交协议的演变:

  • 一阶段:业务数据和回滚日志记录在同一个本地事务中提交,释放本地锁和连接资源。
  • 二阶段:
    • 提交异步化,非常快速地完成。
    • 回滚通过一阶段的回滚日志进行反向补偿。

(2)AT模式与XA模式的区别

  • XA模式一阶段不提交事务,锁定资源;AT模式一阶段直接提交,不锁定资源。
  • XA模式依赖数据库机制实现回滚:AT模式利用数据快照实现数据回滚。
  • XA是强一致性;AT是最终一致性。

Seata分布式事务TCC模式

一、TCC模式介绍

Tcc是分布式事务中二阶段提交协议的实现,它的全称为Tny-Confirm-Cancel,即资源预留(Try)、确认操作(Confirm)、取消操作(Cancel),具体含义如下:

  • Try(prepare)阶段:对业务资源的检查并预留。
  • Confirm(commit)阶段:对y业务处理进行提交,该步骤会对Ty预留的资源进行释放,只要Try成功,Confirm-一定要能成功.
  • Cancel(rollback)阶段:对业务处理进行取消,即回滚操作。

Seata的Tcc模式,整体是两阶段提交的模型。全局事务是由若干分支事务组成的,分支事务要满足两阶段提交的模型要求,即需要每个分支事务都具备自己的:一阶段prepare、二阶段commit或rollback.

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第12张图片

具体的执行流程如下:

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第13张图片

根据两阶段行为模式的不同,我们将分支事务划分为Automatic(Branch)Transaction Mode和TCC(Branch) Transaction Mode.

AT模式基于支持本地ACID事务关系型数据库

  • 一阶段prepare行为:在本地事务中,一并提交业务数据更新和相应回滚日志记录。
  • 二阶段commit行为:马上成功结束,自动异步批量清理回滚日志。
  • 二阶段rollback行为:通过回滚日志,自动生成补偿操作,完成数据回滚。

相应的,TCC模式,不依赖于底层数据资源的事务支持:
·一阶段prepare行为:调用自定义的prepare逻辑。
·二阶段commit行为:调用自定义的commit逻辑。
·二阶段rollback行为:调用自定义的rollback逻辑。

所谓TCC模式,是指支持把自定义的分支事务纳入到全局事务的管理中。

二、案例分析

我们以订单支付为例,Tcc模式下,我们需要手动编码实现事务处理,在ty阶段尝试预留资源,在commit阶段,再把ty阶段预留的资源转入最终表。因此我们需要在业务数据库表中增加预留字段

原始数据

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第14张图片

1、Try阶段

try阶段对资源进行预处理
扣减余额:对余额进行扣减,及冻结余额
扣减库存:对库存进行扣减,增加冻结库存
更新订单:订单状态为支付中

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第15张图片

2、Confirm阶段

confirm阶段业务执行提交,释放预留资源。
扣减余额:解除冻结余额
扣减库存:解除冻结库存
更新订单:修改订单状态为支付成功

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第16张图片

3、Cancel阶段

TCC是一种侵入式的分布式事务解决方案,每个阶段都是独立的事务,与T模式不同的是需要我们手动编码来实现数据恢复。

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第17张图片

TCC是一种侵入式的分布式事务解决方案,每个阶段都是独立的事务,与T模式不同的是需要我们手动编码来实现数据恢复。

对业务系统有着非常大的入侵性,设计相对复杂,对比T,它的优点是TCC完全不依赖数据库,并且因为数据回滚问题都是在业务层面解决的,所以不需要使用全局锁,故执行速度更快。

结合代码对比AT模式和XA模式

开启全局事务AT模式

1.超时导致的回滚+日志分析

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第18张图片

断点运行查看相关的undo log日志

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第19张图片

查看这条日志啥

select CAST(rollback_info as char)rollback_info,branch_id,xid,context,
log_status from storage_db.undo_log

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第20张图片

由于我查询这条SQL语句耗费了时间,超时后数据回滚

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第21张图片

库存微服务两阶段回滚

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第22张图片

2.账户余额不足导致回滚

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第23张图片

账户抛出异常

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第24张图片

订单数据回滚

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第25张图片

库存数据两阶段回滚

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第26张图片

如果未开启全局事务

如果没有开启全局事务,只是用transactional注解

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第27张图片

库存扣减,数据提交

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第28张图片

账户抛出异常,未执行SQL

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第29张图片

执行后数据的对比,订单数据回滚,库存抛异常,未执行SQL,库存扣减成功,数据出现不一致的情况

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第30张图片

执行期间操作对比

(1)Seata AT模式是两阶段提交协议的演变:

  • 一阶段:业务数据和回滚日志记录在同一个本地事务中提交,释放本地锁和连接资源。
  • 二阶段:
    • 提交异步化,非常快速地完成。
    • 回滚通过一阶段的回滚日志进行反向补偿。

(2)AT模式与XA模式的区别

  • XA模式一阶段不提交事务,锁定资源;AT模式一阶段直接提交,不锁定资源。
  • XA模式依赖数据库机制实现回滚:AT模式利用数据快照实现数据回滚。
  • XA是强一致性;AT是最终一致性。

AT模式

设置一下睡眠时间,让seata一直占用资源

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第31张图片

执行SQL语句,修改成功

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第32张图片

AT模式一阶段直接提交,不锁定资源。

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第33张图片

XA模式

如果改成XA模式,XA模式一阶段不提交事务,锁定资源

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第34张图片

锁定资源,一直等到seata执行完毕才能执行

分布式事务(Seata)——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】_第35张图片

附录:

1、账户account的SQL

/*
 Navicat Premium Data Transfer

 Source Server         : 192.168.111.130_BookMall
 Source Server Type    : MySQL
 Source Server Version : 80033
 Source Host           : 192.168.150.101:3306
 Source Schema         : account_db

 Target Server Type    : MySQL
 Target Server Version : 80033
 File Encoding         : 65001

 Date: 26/10/2023 10:42:19
*/

SET NAMES utf8mb4;
SET FOREIGN_KEY_CHECKS = 0;

-- ----------------------------
-- Table structure for account_tbl
-- ----------------------------
DROP TABLE IF EXISTS `account_tbl`;
CREATE TABLE `account_tbl`  (
  `id` int NOT NULL AUTO_INCREMENT,
  `user_id` varchar(255) CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci NULL DEFAULT NULL,
  `money` int NULL DEFAULT 0,
  PRIMARY KEY (`id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8mb3 COLLATE = utf8mb3_general_ci ROW_FORMAT = Dynamic;

-- ----------------------------
-- Records of account_tbl
-- ----------------------------
INSERT INTO `account_tbl` VALUES (1, '1', 50);

-- ----------------------------
-- Table structure for undo_log
-- ----------------------------
DROP TABLE IF EXISTS `undo_log`;
CREATE TABLE `undo_log`  (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `branch_id` bigint NOT NULL,
  `xid` varchar(100) CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci NOT NULL,
  `context` varchar(128) CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci NOT NULL,
  `rollback_info` longblob NOT NULL,
  `log_status` int NOT NULL,
  `log_created` datetime NOT NULL,
  `log_modified` datetime NOT NULL,
  PRIMARY KEY (`id`) USING BTREE,
  UNIQUE INDEX `ux_undo_log`(`xid`, `branch_id`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 1 CHARACTER SET = utf8mb3 COLLATE = utf8mb3_general_ci ROW_FORMAT = Dynamic;

SET FOREIGN_KEY_CHECKS = 1;

2、订单Order的SQL

/*
 Navicat Premium Data Transfer

 Source Server         : 192.168.111.130_BookMall
 Source Server Type    : MySQL
 Source Server Version : 80033
 Source Host           : 192.168.150.101:3306
 Source Schema         : order_db

 Target Server Type    : MySQL
 Target Server Version : 80033
 File Encoding         : 65001

 Date: 26/10/2023 10:44:06
*/

SET NAMES utf8mb4;
SET FOREIGN_KEY_CHECKS = 0;

-- ----------------------------
-- Table structure for order_tbl
-- ----------------------------
DROP TABLE IF EXISTS `order_tbl`;
CREATE TABLE `order_tbl`  (
  `id` int NOT NULL AUTO_INCREMENT,
  `user_id` varchar(255) CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci NULL DEFAULT NULL,
  `commodity_code` varchar(255) CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci NULL DEFAULT NULL,
  `count` int NULL DEFAULT 0,
  `money` int NULL DEFAULT 0,
  `status` int NULL DEFAULT 0,
  PRIMARY KEY (`id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8mb3 COLLATE = utf8mb3_general_ci ROW_FORMAT = Dynamic;

-- ----------------------------
-- Records of order_tbl
-- ----------------------------
INSERT INTO `order_tbl` VALUES (1, '1', '1001', 1, 100, 0);

-- ----------------------------
-- Table structure for undo_log
-- ----------------------------
DROP TABLE IF EXISTS `undo_log`;
CREATE TABLE `undo_log`  (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `branch_id` bigint NOT NULL,
  `xid` varchar(100) CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci NOT NULL,
  `context` varchar(128) CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci NOT NULL,
  `rollback_info` longblob NOT NULL,
  `log_status` int NOT NULL,
  `log_created` datetime NOT NULL,
  `log_modified` datetime NOT NULL,
  PRIMARY KEY (`id`) USING BTREE,
  UNIQUE INDEX `ux_undo_log`(`xid`, `branch_id`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 1 CHARACTER SET = utf8mb3 COLLATE = utf8mb3_general_ci ROW_FORMAT = Dynamic;


SET FOREIGN_KEY_CHECKS = 1;

3、库存Storage的SQL

/*
 Navicat Premium Data Transfer

 Source Server         : 192.168.111.130_BookMall
 Source Server Type    : MySQL
 Source Server Version : 80033
 Source Host           : 192.168.150.101:3306
 Source Schema         : storage_db

 Target Server Type    : MySQL
 Target Server Version : 80033
 File Encoding         : 65001

 Date: 26/10/2023 10:45:46
*/

SET NAMES utf8mb4;
SET FOREIGN_KEY_CHECKS = 0;

-- ----------------------------
-- Table structure for stock_tbl
-- ----------------------------
DROP TABLE IF EXISTS `stock_tbl`;
CREATE TABLE `stock_tbl`  (
  `id` int NOT NULL AUTO_INCREMENT,
  `commodity_code` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NULL DEFAULT NULL,
  `count` int NULL DEFAULT 0,
  PRIMARY KEY (`id`) USING BTREE,
  UNIQUE INDEX `commodity_code`(`commodity_code`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8mb4 COLLATE = utf8mb4_0900_ai_ci ROW_FORMAT = Dynamic;

-- ----------------------------
-- Records of stock_tbl
-- ----------------------------
INSERT INTO `stock_tbl` VALUES (1, '1001', 10);

-- ----------------------------
-- Table structure for undo_log
-- ----------------------------
DROP TABLE IF EXISTS `undo_log`;
CREATE TABLE `undo_log`  (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `branch_id` bigint NOT NULL,
  `xid` varchar(100) CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci NOT NULL,
  `context` varchar(128) CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci NOT NULL,
  `rollback_info` longblob NOT NULL,
  `log_status` int NOT NULL,
  `log_created` datetime NOT NULL,
  `log_modified` datetime NOT NULL,
  PRIMARY KEY (`id`) USING BTREE,
  UNIQUE INDEX `ux_undo_log`(`xid`, `branch_id`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 1 CHARACTER SET = utf8mb3 COLLATE = utf8mb3_general_ci ROW_FORMAT = Dynamic;


SET FOREIGN_KEY_CHECKS = 1;

总结

1、XA规范使用两阶段提交(2PC,Two-Phase Commit)来保证所有资源同时提交或回滚任何特定的事务。

  • 第一阶段为准备(prepare)阶段。即所有的参与者准备执行事务并锁住需要的资源。参与者ready时,向transaction manager报告已准备就绪。
  • 第二阶段为提交阶段(commit)。当transaction manager确认所有参与者都ready)后,向所有参与者发送commit命令。

2、AT模式与XA模式

(1)Seata AT模式是两阶段提交协议的演变:

  • 一阶段:业务数据和回滚日志记录在同一个本地事务中提交,释放本地锁和连接资源。
  • 二阶段:
    • 提交异步化,非常快速地完成。
    • 回滚通过一阶段的回滚日志进行反向补偿。

(2)AT模式与XA模式的区别

  • XA模式一阶段不提交事务,锁定资源;AT模式一阶段直接提交,不锁定资源。
  • XA模式依赖数据库机制实现回滚:AT模式利用数据快照实现数据回滚。
  • XA是强一致性;AT是最终一致性。

3、Tny-Confirm-Cancel,TCC模式

TCC是分布式事务中二阶段提交协议的实现,它的全称为Tny-Confirm-Cancel,即资源预留(Try)、确认操作(Confirm)、取消操作(Cancel),具体含义如下:

  • Try(prepare)阶段:对业务资源的检查并预留。
  • Confirm(commit)阶段:对y业务处理进行提交,该步骤会对Ty预留的资源进行释放,只要Try成功,Confirm-一定要能成功.
  • Cancel(rollback)阶段:对业务处理进行取消,即回滚操作。

你可能感兴趣的:(SpringBoot,分布式)