手机建站cms,网站投放,郑州网站建设技术托管,高端营销型网站前言
事务(TRANSACTION)是一个不可分割的逻辑单元#xff0c;包含了一组数据库操作命令#xff0c;并且把所有的命令作为一个整体向系统提交#xff0c;要么都执行、要么都不执行。
事务作为系统中必须考虑的问题#xff0c;无论是在单体项目还是在分布式项目中都需要进行…
前言
事务(TRANSACTION)是一个不可分割的逻辑单元包含了一组数据库操作命令并且把所有的命令作为一个整体向系统提交要么都执行、要么都不执行。
事务作为系统中必须考虑的问题无论是在单体项目还是在分布式项目中都需要进行处理而尤其在分布式微服务调用的情况下事务的处理就变得复杂。
本篇博客进行了Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比阐述了三种模式的联系和不同并结合案例分析了seata的作用对比了XA模式和AT模式下对执行其他操作的影响。
本篇博客源码以及seata1.4版本的安装包见下面git地址 https://gitee.com/pet365/seta-demo 关于分布式事务CAP理论见下面博客
分布式事务——CAP理论 解决分布式事务的思路 Seata组件初识 和 部署 SpringCloud其他相关的组件博客文章合集如下
【合集】Spring Cloud 组件——架构进化史话 EurekaNacosOpenFeignRibbonSentinelGateway . . . 目录 前言引出Seata分布式事务XA模式一、Java中分布式事务解决方案JTA1、什么是XA2、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的SQL2、订单Order的SQL3、库存Storage的SQL 总结 引出 1、XA规范使用两阶段提交(2PC,Two-Phase Commit)来保证所有资源同时提交或回滚任何特定的事务。
第一阶段为准备(prepare)阶段。即所有的参与者准备执行事务并锁住需要的资源。参与者ready时向transaction manager报告已准备就绪。第二阶段为提交阶段(commit)。当transaction manager确认所有参与者都ready)后向所有参与者发送commit命令。
2、AT模式与XA模式
1Seata AT模式是两阶段提交协议的演变
一阶段业务数据和回滚日志记录在同一个本地事务中提交释放本地锁和连接资源。二阶段 提交异步化非常快速地完成。回滚通过一阶段的回滚日志进行反向补偿。
2AT模式与XA模式的区别
XA模式一阶段不提交事务锁定资源AT模式一阶段直接提交不锁定资源。XA模式依赖数据库机制实现回滚AT模式利用数据快照实现数据回滚。XA是强一致性AT是最终一致性。
3、Tny-Confirm-CancelTCC模式
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 XA模式
http://seata.io/zh-cn/index.html
在Seata定义的分布式事务框架内利用事务资源数据库、消息服务等对XA协议的支持以XA协议的机制来管理分支事务的一种事务模式。
XA模式需要事务资源数据库、消息服务等支持XA协议比如mysql把redolog分为两个阶段。
1、执行阶段
RM一阶段的工作XA start/XA end/XA prepareSQL注册分支 注册分支事务到TC XA Start,Seata全局事务的XID和Branchld关联起来以便由TC 驱动 XA 分支的提交或回滚 执行分支事务但不提交 业务SQL操作放在XA分支中进行由资源对XA协议的支持来保证可回滚XA分支完成后执行XA prepare,同样由资源对XA协议的支持来保证持久化即之后任何意外都不会造成无法回滚的情况) 报告执行状态到TC 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日志表中报告事务状态 第二阶段RM的工作
如果此时所有微服务都执行完并且没有出现异常情况事务协调者TC通知RM删除udo-log记录 如果此时中途有微服务出现异常情况则TC会通知RM根据udo-log记录的对应快照恢复数据到更新前 2、执行流程 二、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;分支事务表branch table,在seata的数据库中创建全局事务表global_table,在seatal的数据库中创建全局锁表lock table,在seata的数据库中创建
全局事务表跟分支事务表是一对多的关系一个全局事务对应多个分支事务。
2、AT模式与XA模式
1Seata AT模式是两阶段提交协议的演变
一阶段业务数据和回滚日志记录在同一个本地事务中提交释放本地锁和连接资源。二阶段 提交异步化非常快速地完成。回滚通过一阶段的回滚日志进行反向补偿。
2AT模式与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. 具体的执行流程如下 根据两阶段行为模式的不同我们将分支事务划分为Automatic(Branch)Transaction Mode和TCC(Branch) Transaction Mode.
AT模式基于支持本地ACID事务的关系型数据库
一阶段prepare行为在本地事务中一并提交业务数据更新和相应回滚日志记录。二阶段commit行为马上成功结束自动异步批量清理回滚日志。二阶段rollback行为通过回滚日志自动生成补偿操作完成数据回滚。
相应的TCC模式不依赖于底层数据资源的事务支持
一阶段prepare行为调用自定义的prepare逻辑。二阶段commit行为调用自定义的commit逻辑。二阶段rollback行为调用自定义的rollback逻辑。
所谓TCC模式是指支持把自定义的分支事务纳入到全局事务的管理中。
二、案例分析
我们以订单支付为例TCC模式下我们需要手动编码实现事务处理在try阶段尝试预留资源在commit阶段再把try阶段预留的资源转入最终表。因此我们需要在业务数据库表中增加预留字段
原始数据 1、Try阶段
try阶段对资源进行预处理 扣减余额对余额进行扣减及冻结余额 扣减库存对库存进行扣减增加冻结库存 更新订单订单状态为支付中 2、Confirm阶段
confirm阶段业务执行提交释放预留资源。 扣减余额解除冻结余额 扣减库存解除冻结库存 更新订单修改订单状态为支付成功 3、Cancel阶段
TCC是一种侵入式的分布式事务解决方案每个阶段都是独立的事务与AT模式不同的是需要我们手动编码来实现数据恢复。 TCC是一种侵入式的分布式事务解决方案每个阶段都是独立的事务与T模式不同的是需要我们手动编码来实现数据恢复。
对业务系统有着非常大的入侵性设计相对复杂对比AT,它的优点是TCC完全不依赖数据库并且因为数据回滚问题都是在业务层面解决的所以不需要使用全局锁故执行速度更快。
结合代码对比AT模式和XA模式
开启全局事务AT模式
1.超时导致的回滚日志分析 断点运行查看相关的undo log日志 查看这条日志啥 select CAST(rollback_info as char)rollback_info,branch_id,xid,context,
log_status from storage_db.undo_log由于我查询这条SQL语句耗费了时间超时后数据回滚 库存微服务两阶段回滚 2.账户余额不足导致回滚 账户抛出异常 订单数据回滚 库存数据两阶段回滚 如果未开启全局事务 如果没有开启全局事务只是用transactional注解 库存扣减数据提交 账户抛出异常未执行SQL 执行后数据的对比订单数据回滚库存抛异常未执行SQL库存扣减成功数据出现不一致的情况 执行期间操作对比
1Seata AT模式是两阶段提交协议的演变
一阶段业务数据和回滚日志记录在同一个本地事务中提交释放本地锁和连接资源。二阶段 提交异步化非常快速地完成。回滚通过一阶段的回滚日志进行反向补偿。
2AT模式与XA模式的区别
XA模式一阶段不提交事务锁定资源AT模式一阶段直接提交不锁定资源。XA模式依赖数据库机制实现回滚AT模式利用数据快照实现数据回滚。XA是强一致性AT是最终一致性。
AT模式 设置一下睡眠时间让seata一直占用资源 执行SQL语句修改成功 AT模式一阶段直接提交不锁定资源。 XA模式 如果改成XA模式XA模式一阶段不提交事务锁定资源 锁定资源一直等到seata执行完毕才能执行 附录
1、账户account的SQL
/*Navicat Premium Data TransferSource Server : 192.168.111.130_BookMallSource Server Type : MySQLSource Server Version : 80033Source Host : 192.168.150.101:3306Source Schema : account_dbTarget Server Type : MySQLTarget Server Version : 80033File Encoding : 65001Date: 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 TransferSource Server : 192.168.111.130_BookMallSource Server Type : MySQLSource Server Version : 80033Source Host : 192.168.150.101:3306Source Schema : order_dbTarget Server Type : MySQLTarget Server Version : 80033File Encoding : 65001Date: 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 TransferSource Server : 192.168.111.130_BookMallSource Server Type : MySQLSource Server Version : 80033Source Host : 192.168.150.101:3306Source Schema : storage_dbTarget Server Type : MySQLTarget Server Version : 80033File Encoding : 65001Date: 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模式
1Seata AT模式是两阶段提交协议的演变
一阶段业务数据和回滚日志记录在同一个本地事务中提交释放本地锁和连接资源。二阶段 提交异步化非常快速地完成。回滚通过一阶段的回滚日志进行反向补偿。
2AT模式与XA模式的区别
XA模式一阶段不提交事务锁定资源AT模式一阶段直接提交不锁定资源。XA模式依赖数据库机制实现回滚AT模式利用数据快照实现数据回滚。XA是强一致性AT是最终一致性。
3、Tny-Confirm-CancelTCC模式
TCC是分布式事务中二阶段提交协议的实现它的全称为Tny-Confirm-Cancel,即资源预留(Try)、确认操作(Confirm)、取消操作(Cancel),具体含义如下
Try(prepare)阶段对业务资源的检查并预留。Confirm(commit)阶段对y业务处理进行提交该步骤会对Ty预留的资源进行释放只要Try成功Confirm-一定要能成功.Cancel(rollback)阶段对业务处理进行取消即回滚操作。
