事务
事务是由一个有限的数据库操作序列构成，这些操作要么全部执行,要么全部不执行，是一个不可分割的工作单位。
事务四个典型特性，即ACID，原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。
-
原子性： 事务作为一个整体被执行，包含在其中的对数据库的操作要么全部都执行，要么都不执行。
-
一致性： 指在事务开始之前和事务结束以后，数据不会被破坏，假如A账户给B账户转10块钱，不管成功与否，A和B的总金额是不变的。
-
隔离性： 多个事务并发访问时，事务之间是相互隔离的，一个事务不应该被其他事务干扰，多个并发事务之间要相互隔离。。
-
持久性： 表示事务完成提交后，该事务对数据库所作的操作更改，将持久地保存在数据库之中
MySQL的rollback思想
mysql定义了两张表undo log和redo log其中undo log是记录数据被修改前的信息以及新增和删除的数据信息，当事务需要回滚时会根据undo log里面记录的信息生成对应的sql语句进行回滚。如：
-
如果在回滚日志里有新增数据记录，则生成删除该条的语句；
-
如果在回滚日志里有删除数据记录，则生成生成该条的语句；
-
如果在回滚日志里有修改数据记录，则生成修改到原先数据的语句。
redo log主要是记录用户操作提交的数据日志，用于数据的数据的持久化。redo log持久化到磁盘中，当系统重启后会读取redo log恢复数据。
-
事务的原子性是通过 undo log 来实现的
-
事务的持久性性是通过 redo log 来实现的
spring事务
spring对事务的支持主要是通过操作数据库对事务进行操作。没有数据库的事务支持，spring无法提供事务的功能。而对于纯jdbc操作数据库的事务，有以下方法：
1. 获取连接 Connection con = DriverManager.getConnection() 2. 开启事务con.setAutoCommit(true/false); 3. 执行CRUD 4. 提交事务/回滚事务 con.commit() / con.rollback(); 5. 关闭连接 conn.close();
spring可以通过@Transactional注解进行事务管理，让我们不用书写2和4的代码。@Transactional主要是通过aop和ioc技术来完成实现的。同时注意@Transactional不生效的三种情况：
-
@Transactional注解标注方法修饰符为非public时不生效。@Transactional是基于动态代理实现的，@Transactional注解实现原理中分析了实现方法，在bean初始化过程中，对含有@Transactional标注的bean实例创建代理对象，这里就存在一个spring扫描@Transactional注解信息的过程，不幸的是源码中体现，标注@Transactional的方法如果修饰符不是public，那么就默认方法的@Transactional信息为空，那么将不会对bean进行代理对象创建或者不会对方法进行代理调用
-
在类内部调用调用类内部@Transactional标注的方法时不生效。事务管理是基于动态代理对象的代理逻辑实现的，那么如果在类内部调用类内部的事务方法，这个调用事务方法的过程并不是通过代理对象来调用的，而是直接通过this对象来调用方法，不存在代理对象。
-
try catch中捕获了异常却没将异常抛出（或者抛出的异常不属于@Transactional的捕获异常范围）
参考文章：【spring 】spring 的事务(transaction、事务的传播属性、隔离级别) 一 基础概念介绍_transactiondefinition 默认事务传播类型-CSDN博客
spring事务的传播属性
什么是事务的传播行为呢？
-
就是当一个事务方法被另一个事务方法调用时，这个事务方法应该如何进行事务控制。
例如：两个事务方法，一个A方法，一个B方法。在这两个方法上都添加了@Transactional注解，就代表这两个方法都具有事务，而在A方法当中又去调用了B方法。
所谓事务的传播行为，指的就是在A方法运行的时候，首先会开启一个事务，在A方法当中又调用了B方法， B方法自身也具有事务，那么B方法在运行的时候，到底是加入到A方法的事务当中来，还是B方法在运行的时候新建一个事务？这个就涉及到了事务的传播行为。
我们要想控制事务的传播行为，在@Transactional注解的后面指定一个属性propagation，通过 propagation 属性来指定传播行为。接下来我们就来介绍一下常见的事务传播行为。
| 属性值 | 含义 |
|---|---|
| REQUIRED | 【默认值】需要事务，有则加入，无则创建新事务 |
| REQUIRES_NEW | 需要新事务，无论有无，总是创建新事务 |
| SUPPORTS | 支持事务，有则加入，无则在无事务状态中运行 |
| NOT_SUPPORTED | 不支持事务，在无事务状态下运行,如果当前存在已有事务,则挂起当前事务 |
| MANDATORY | 必须有事务，否则抛异常 |
| NEVER | 必须没事务，否则抛异常 |
| NESTED | 嵌套事务 |
嵌套事务呈现父子事务概念，二者之间是有关联的，核心思想就是子事务不会独立提交，而是取决于父事务，当父事务提交，那么子事务才会随之提交；如果父事务回滚，那么子事务也回滚。
与此相反，PROPAGATION_REQUIRES_NEW的内层事务，会立即提交，与外层毫无关联。
但是子事务又有自己的特性，那 就是可以独立进行回滚，不会引发父事务整体的回滚(当然需要try catch子事务，避免异常传递至父层事务，如果没有，则也会引发父事务整体回滚)。这个特性比较有意思，虽然不能独立提交，但是可以独立回滚，因此，如果存在ABC 三个子事务，那么每个子事务都可以独立回滚，子事务类似一个游戏中的保存点，假设某个时间点，创建了一个保存点A，角色有10发子弹，主线继续发生时，对应执行某个子事务内的逻辑，如果游戏角色打了4发子弹，剩余6发子弹时挂了，点击返回上一个保存点，可以重新玩一次，此时该角色又是10发子弹，对应的就是子事务发生异常，子事务回滚到事务执行之前的那个点，放佛从来没有执行过该子事务一样，数据库的数据也不会发生变更。更重要的是，游戏角色仅会返回到某个进度的保存点，而不是返回到游戏的开始点，否则进度丢了，都想骂人了。
子事务可以独立回滚，也可以通过传递异常，让父事务也回滚，根源在于用户策略，在父事务通过try catch 对子事务进行包裹，灵活策略；
该传播机制的特点是可以保存状态保存点，当前事务回滚到某一个点，从而避免所有的嵌套事务都回滚，即各自回滚各自的，如果子事务没有把异常吃掉，基本还是会引起全部回滚的
原文链接：【spring】spring 的事务(transaction) 四 嵌套事务PROPAGATION_NESTED-CSDN博客
分布式事务
分布式事务就是指不是在单个服务或单个数据库架构下，产生的事务，例如：跨数据源的分布式事务，跨服务的分布式事务。
CAP定理：
-
Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致。
-
Availability （可用性）：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝。
-
Partition（分区）：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。
CAP定理的矛盾：
· 在分布式系统中，系统间的网络不能100%保证健康，一定会有故障的时候，而服务有必须对外保证服务。因此Partition Tolerance不可避免。
当节点接收到新的数据变更时，就会出现问题了：
如果此时要保证一致性，就必须等待网络恢复，完成数据同步后，整个集群才对外提供服务，服务处于阻塞状态，不可用。
如果此时要保证可用性，就不能等待网络恢复，那node01、node02与node03之间就会出现数据不一致。
也就是说，在P一定会出现的情况下，A和C之间只能实现一个。
BASE理论:
-
Basically Available （基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
-
Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态。
-
Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。
解决分布式事务思路
分布式事务最大的问题是各个子事务的一致性问题，因此可以借鉴CAP定理和BASE理论，有两种解决思路：
-
AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。
-
CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。
这里的子事务是指子系统事务又称分支事务，有关联的各个子事务在一起称为全局事务。
Seata的架构
Seata事务管理中有三个重要的角色：
-
TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。
-
TM (Transaction Manager) - 事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。
-
RM (Resource Manager) - 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
整体的架构如图：
Seata基于上述架构提供了四种不同的分布式事务解决方案：
-
XA模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入
-
TCC模式：最终一致的分阶段事务模式，有业务侵入
-
AT模式：最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式
-
SAGA模式：长事务模式，有业务侵入
spring整合seata
一、部署Seata的tc-server
-
下载seata-server包并解压，修改registry.conf配置文件
-
在nacos中添加seata的配置文件
-
在本地创建tc服务有关的数据库
-
进入bin目录，点击saeta-server.bat启动TC服务。启动成功后登录nacos的服务列表可以看见已经注册了。
修改registry.conf配置文件:
注意：配置文件要和nacos中的配置文件相呼应
registry {
# tc服务的注册中心类，这里选择nacos，也可以是eureka、zookeeper等
type = "nacos"
nacos {
# seata tc 服务注册到 nacos的服务名称，可以自定义
application = "seata-tc-server"
serverAddr = "127.0.0.1:8848"
group = "DEFAULT_GROUP"
namespace = ""
# 集群名称要与application中的配置文件一致
cluster = "SH"
username = "nacos"
password = "nacos"
}
}
config {
# 读取tc服务端的配置文件的方式，这里是从nacos配置中心读取，这样如果tc是集群，可以共享配置
type = "nacos"
# 配置nacos地址等信息
nacos {
serverAddr = "127.0.0.1:8848"
namespace = ""
group = "SEATA_GROUP"
username = "nacos"
password = "nacos"
dataId = "seataServer.properties"
}
}
在nacos中添加seata的配置文件:
# 数据存储方式，db代表数据库 store.mode=db store.db.datasource=druid store.db.dbType=mysql store.db.driverClassName=com.mysql.cj.jdbc.Driver store.db.url=jdbc:mysql://127.0.0.1:3306/seata?useUnicode=true&rewriteBatchedStatements=true store.db.user=root store.db.password=123 store.db.minConn=5 store.db.maxConn=30 store.db.globalTable=global_table store.db.branchTable=branch_table store.db.queryLimit=100 store.db.lockTable=lock_table store.db.maxWait=5000 # 事务、日志等配置 server.recovery.committingRetryPeriod=1000 server.recovery.asynCommittingRetryPeriod=1000 server.recovery.rollbackingRetryPeriod=1000 server.recovery.timeoutRetryPeriod=1000 server.maxCommitRetryTimeout=-1 server.maxRollbackRetryTimeout=-1 server.rollbackRetryTimeoutUnlockEnable=false server.undo.logSaveDays=7 server.undo.logDeletePeriod=86400000 # 客户端与服务端传输方式 transport.serialization=seata transport.compressor=none # 关闭metrics功能，提高性能 metrics.enabled=false metrics.registryType=compact metrics.exporterList=prometheus metrics.exporterPrometheusPort=9898
其中的数据库地址、用户名、密码都需要修改成你自己的数据库信息。
创建数据库表，创建一个名为seata的数据库，并执行下列sql
SET NAMES utf8mb4; SET FOREIGN_KEY_CHECKS = 0; -- ---------------------------- -- 分支事务表 -- ---------------------------- DROP TABLE IF EXISTS `branch_table`; CREATE TABLE `branch_table` ( `branch_id` bigint(20) NOT NULL, `xid` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL, `transaction_id` bigint(20) NULL DEFAULT NULL, `resource_group_id` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL, `resource_id` varchar(256) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL, `branch_type` varchar(8) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL, `status` tinyint(4) NULL DEFAULT NULL, `client_id` varchar(64) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL, `application_data` varchar(2000) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL, `gmt_create` datetime(6) NULL DEFAULT NULL, `gmt_modified` datetime(6) NULL DEFAULT NULL, PRIMARY KEY (`branch_id`) USING BTREE, INDEX `idx_xid`(`xid`) USING BTREE ) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact; -- ---------------------------- -- 全局事务表 -- ---------------------------- DROP TABLE IF EXISTS `global_table`; CREATE TABLE `global_table` ( `xid` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL, `transaction_id` bigint(20) NULL DEFAULT NULL, `status` tinyint(4) NOT NULL, `application_id` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL, `transaction_service_group` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL, `transaction_name` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL, `timeout` int(11) NULL DEFAULT NULL, `begin_time` bigint(20) NULL DEFAULT NULL, `application_data` varchar(2000) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL, `gmt_create` datetime NULL DEFAULT NULL, `gmt_modified` datetime NULL DEFAULT NULL, PRIMARY KEY (`xid`) USING BTREE, INDEX `idx_gmt_modified_status`(`gmt_modified`, `status`) USING BTREE, INDEX `idx_transaction_id`(`transaction_id`) USING BTREE ) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact; SET FOREIGN_KEY_CHECKS = 1;
二、微服务集成seata
在微服务中引入seata依赖：
注意：所有涉及全局事务的服务都要引入此依赖及其配置
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-seata</artifactId>
<exclusions>
<!--版本较低，1.3.0，因此排除-->
<exclusion>
<artifactId>seata-spring-boot-starter</artifactId>
<groupId>io.seata</groupId>
</exclusion>
</exclusions>
</dependency>
<!--seata starter 采用1.4.2版本-->
<dependency>
<groupId>io.seata</groupId>
<artifactId>seata-spring-boot-starter</artifactId>
<version>${seata.version}</version>
</dependency>
2.配置TC地址
需要修改application.yml文件，添加一些配置：
注意：涉及全局事务的微服务都要增加此配置
seata: registry: # TC服务注册中心的配置，微服务根据这些信息去注册中心获取tc服务地址 # 参考tc服务自己的registry.conf中的配置 type: nacos nacos: # tc server-addr: 127.0.0.1:8848 namespace: "" group: SEATA_GROUP # 分组名要入registry.conf中的配置一致 application: seata-tc-server # tc服务在nacos中的服务名称 cluster: SH tx-service-group: seata-demo # 事务组，根据这个获取tc服务的cluster名称 service: vgroup-mapping: # 事务组与TC服务cluster的映射关系 seata-demo: SH
微服务根据配置寻找nacos中注册的tc服务所需信息：
-
namespace：命名空间
-
group：分组
-
application：服务名
-
cluster：集群名
namespace为空，就是默认的public
三、模式配置：
3、1 XA模式
XA 规范 是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准，XA 规范 描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对 XA 规范 提供了支持。实现的原理都是基于两阶段提交。
一阶段：
-
事务协调者通知每个事物参与者执行本地事务
-
本地事务执行完成后报告事务执行状态给事务协调者，此时事务不提交，继续持有数据库锁
二阶段：
-
事务协调者基于一阶段的报告来判断下一步操作
-
如果一阶段都成功，则通知所有事务参与者，提交事务
-
如果一阶段任意一个参与者失败，则通知所有事务参与者回滚事务
-
正常情况：
异常情况
3、1、1 Seata的XA模型：
Seata对原始的XA模式做了简单的封装和改造，以适应自己的事务模型，基本架构如图：
RM一阶段的工作：
① 注册分支事务到TC
② 执行分支业务sql但不提交
③ 报告执行状态到TC
TC二阶段的工作：
-
TC检测各分支事务执行状态
a.如果都成功，通知所有RM提交事务
b.如果有失败，通知所有RM回滚事务
RM二阶段的工作：
-
接收TC指令，提交或回滚事务
3、1、2 优缺点
XA模式的优点是什么？
-
事务的强一致性，满足ACID原则。
-
常用数据库都支持，实现简单，并且没有代码侵入
XA模式的缺点是什么？
-
因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差
-
依赖关系型数据库实现事务
3、1、3 实现XA模式
修改各项微服务的application.yml文件，开启XA模式
seata: data-source-proxy-mode: XA
在全局事务的入口方法上添加@GlobalTrasaction注解：
3、2 AT模式
AT模式同样是分阶段提交的事务模型，不过缺弥补了XA模型中资源锁定周期过长的缺陷。
3、2、1 Seata的AT模型
基本流程图：
阶段一RM的工作：
-
注册分支事务
-
记录undo-log（数据快照）
-
执行业务sql并提交
-
报告事务状态
阶段二提交时RM的工作：
-
删除undo-log即可
阶段二回滚时RM的工作：
-
根据undo-log恢复数据到更新前
流程图
3.2.2.AT与XA的区别
-
XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源。
-
XA模式依赖数据库机制实现回滚；AT模式利用数据快照实现数据回滚。
-
XA模式强一致；AT模式最终一致
3.2.3.脏写问题
在多线程并发访问AT模式的分布式事务时，有可能出现脏写问题，如图：
解决思路就是引入了全局锁的概念。在释放DB锁之前，先拿到全局锁。避免同一时刻有另外一个事务来操作当前数据。
脏写问题通过引入全局锁得以解决
3.2.4.优缺点
AT模式的优点：
-
一阶段完成直接提交事务，释放数据库资源，性能比较好
-
利用全局锁实现读写隔离
-
没有代码侵入，框架自动完成回滚和提交
AT模式的缺点：
-
两阶段之间属于软状态，属于最终一致
-
框架的快照功能会影响性能，但比XA模式要好很多
3.2.5.实现AT模式
AT模式中的快照生成、回滚等动作都是由框架自动完成，没有任何代码侵入，因此实现非常简单。只不过，AT模式需要一个表来记录全局锁、另一张表来记录数据快照undo_log。
-
导入数据库表，记录全局锁和快照。全局锁表lock_table导入到与TC服务关联的数据库中,undo_log导入到微服务关联的数据库
-
修改application.yml文件。修改事务模式为AT
-
在全局事务调用的方法上加入@GlobalTransactional注解
lock_table
DROP TABLE IF EXISTS `lock_table`; CREATE TABLE `lock_table` ( `row_key` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL, `xid` varchar(96) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL, `transaction_id` bigint(20) NULL DEFAULT NULL, `branch_id` bigint(20) NOT NULL, `resource_id` varchar(256) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL, `table_name` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL, `pk` varchar(36) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL, `gmt_create` datetime NULL DEFAULT NULL, `gmt_modified` datetime NULL DEFAULT NULL, PRIMARY KEY (`row_key`) USING BTREE, INDEX `idx_branch_id`(`branch_id`) USING BTREE ) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact; SET FOREIGN_KEY_CHECKS = 1;
undo_log表
SET NAMES utf8mb4; SET FOREIGN_KEY_CHECKS = 0; -- ---------------------------- -- Table structure for undo_log -- ---------------------------- DROP TABLE IF EXISTS `undo_log`; CREATE TABLE `undo_log` ( `branch_id` bigint(20) NOT NULL COMMENT 'branch transaction id', `xid` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT 'global transaction id', `context` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT 'undo_log context,such as serialization', `rollback_info` longblob NOT NULL COMMENT 'rollback info', `log_status` int(11) NOT NULL COMMENT '0:normal status,1:defense status', `log_created` datetime(6) NOT NULL COMMENT 'create datetime', `log_modified` datetime(6) NOT NULL COMMENT 'modify datetime', UNIQUE INDEX `ux_undo_log`(`xid`, `branch_id`) USING BTREE ) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci COMMENT = 'AT transaction mode undo table' ROW_FORMAT = Compact;
2、修改配置。注意此配置在所有涉及全局事务的微服务中都要配置
seata: data-source-proxy-mode: AT # 默认就是AT
3.3.TCC模式
TCC模式与AT模式非常相似，每阶段都是独立事务，不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法：
-
Try：资源的检测和预留；
-
Confirm：完成资源操作业务；要求 Try 成功 Confirm 一定要能成功。
-
Cancel：预留资源释放，可以理解为try的反向操作。
3.3.1.流程分析
举例，一个扣减用户余额的业务。假设账户A原来余额是100，需要余额扣减30元。
-
阶段一（ Try ）：检查余额是否充足，如果充足则冻结金额增加30元，可用余额扣除30
初识余额：
余额充足，可以冻结：
此时，总金额 = 冻结金额 + 可用金额，数量依然是100不变。事务直接提交无需等待其它事务。
-
阶段二（Confirm)：假如要提交（Confirm），则冻结金额扣减30
确认可以提交，不过之前可用金额已经扣减过了，这里只要清除冻结金额就好了：
此时，总金额 = 冻结金额 + 可用金额 = 0 + 70 = 70元
-
阶段二(Canncel)：如果要回滚（Cancel），则冻结金额扣减30，可用余额增加30
需要回滚，那么就要释放冻结金额，恢复可用金额：
3.3.2.Seata的TCC模型
Seata中的TCC模型依然延续之前的事务架构，如图：
3.3.3.优缺点
TCC模式的每个阶段的任务
-
Try：资源检查和预留
-
Confirm：业务执行和提交
-
Cancel：预留资源的释放
TCC的优点
-
一阶段完成直接提交事务，释放数据库资源，性能好
-
相比AT模型，无需生成快照，无需使用全局锁，性能最强
-
不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库
TCC的缺点
-
有代码侵入，需要人为编写try、Confirm和Cancel接口，太麻烦
-
软状态，事务是最终一致
-
需要考虑Confirm和Cancel的失败情况，做好幂等处理
3.3.4.事务悬挂和空回滚
1）空回滚
当某分支事务的try阶段阻塞时，可能导致全局事务超时而触发二阶段的cancel操作。在未执行try操作时先执行了cancel操作，这时cancel不能做回滚，就是空回滚。
如图：
执行cancel操作时，应当判断try是否已经执行，如果尚未执行，则应该空回滚。
2）业务悬挂
对于已经空回滚的业务，之前被阻塞的try操作恢复，继续执行try，但是由于前面已经存在空回滚了，回滚后事务已经结束了，就永远不可能confirm或cancel ，事务一直处于中间状态，这就是业务悬挂。
执行try操作时，应当判断cancel是否已经执行过了，如果已经执行，应当阻止空回滚后的try操作，避免悬挂
3）幂等性
幂等性就是无论接口调用多少次，返回的结果应该具有一致性。
3.3.5.实现TCC模式
-
根据业务逻辑，在对应的微服务生成数据库表
-
在对应的微服务中生成对应的TCC接口，接口类上要用seata下的@LocalTCC注解声明TCC模式。
-
根据业务逻辑编写实现类
1）定义数据库表并生成对应的实体类及Mapper文件
本次实验以扣减余额业务为例，为余额服务生成对应的数据库表.可用余额有原本的数据库account文件支持，本sql主要建立冻结余额
CREATE TABLE `account_freeze` ( `xid` varchar(128) NOT NULL, `user_id` varchar(255) DEFAULT NULL COMMENT '用户id', `freeze_money` int(11) unsigned DEFAULT '0' COMMENT '冻结金额', `state` int(1) DEFAULT NULL COMMENT '事务状态，0:try，1:confirm，2:cancel', PRIMARY KEY (`xid`) USING BTREE ) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=COMPACT;
对应实体类
@Data
@TableName("account_freeze")
public class AccountFreeze {
@TableId(type = IdType.INPUT)
private String xid;
private String userId;
private Integer freezeMoney;
private Integer state;
public static abstract class State {
public final static int TRY = 0;
public final static int CONFIRM = 1;
public final static int CANCEL = 2;
}
}
Mapper文件
@Mapper
public interface AccountFreezeMapper extends BaseMapper<AccountFreeze> {
}
其中：
-
xid：是全局事务id
-
freeze_money：用来记录用户冻结金额
-
state：用来记录事务状态
-
Try业务：
-
记录冻结金额和事务状态到account_freeze表
-
扣减account表可用金额
-
-
Confirm业务
-
根据xid删除account_freeze表的冻结记录
-
-
Cancel业务
-
修改account_freeze表，冻结金额为0，state为2
-
修改account表，恢复可用金额
-
-
如何判断是否空回滚？
-
cancel业务中，根据xid查询account_freeze，如果为null则说明try还没做，需要空回滚
-
-
如何避免业务悬挂？
-
try业务中，根据xid查询account_freeze ，如果已经存在则证明Cancel已经执行，拒绝执行try业务
-
2）声明TCC接口
-
@LocalTCC：
该注解需要添加到上面描述的接口上，表示实现该接口的类被 seata 来管理，seata 根据事务的状态，自动调用我们定义的方法，如果没问题则调用 Commit 方法，否则调用 Rollback 方法。
-
@TwoPhaseBusinessAction：
该注解用在接口的 Try 方法上。
-
@BusinessActionContextParameter：
该注解用来修饰 Try 方法的入参，被修饰的入参可以在 Commit 方法和 Rollback 方法中通过 BusinessActionContext 获取。
-
BusinessActionContext：
在接口方法的实现代码中，可以通过 BusinessActionContext 来获取参数, BusinessActionContext 就是 seata tcc 的事务上下文，用于存放 tcc 事务的一些关键数据。BusinessActionContext 对象可以直接作为 commit 方法和 rollbakc 方法的参数，Seata 会自动注入参数。
package cn.itcast.account.service;
import io.seata.rm.tcc.api.BusinessActionContext;
import io.seata.rm.tcc.api.BusinessActionContextParameter;
import io.seata.rm.tcc.api.LocalTCC;
import io.seata.rm.tcc.api.TwoPhaseBusinessAction;
//
// @LocalTCC 该注解需要添加到上面描述的接口上，表示实现该接口的类被 seata 来管理，
// seata 根据事务的状态，自动调用我们定义的方法，如果没问题则调用 Commit 方法，
// 否则调用 Rollback 方法。
@LocalTCC
public interface AccountTCCService {
// @TwoPhaseBusinessAction 注解用于接口的try方法上
//
// @BusinessActionContextParameter 该注解用来修饰 Try 方法的入参，
// 被修饰的入参可以在 Commit 方法和 Rollback 方法中通过
// BusinessActionContext 获取
//
// BusinessActionContext 在接口方法的实现代码中，
// 可以通过 BusinessActionContext 来获取参数,
// BusinessActionContext 就是 seata tcc 的事务上下文，
// 用于存放 tcc 事务的一些关键数据。BusinessActionContext 对象可以
// 直接作为 commit 方法和 rollbakc 方法的参数，Seata 会自动注入参数
@TwoPhaseBusinessAction(name = "deduct",
commitMethod = "confirm", rollbackMethod = "cancel")
void deduct(@BusinessActionContextParameter(paramName = "userId") String userId,
@BusinessActionContextParameter(paramName = "money") int money);
boolean confirm(BusinessActionContext ctx);
boolean cancel(BusinessActionContext ctx);
}
3）根据业务逻辑编写实现类
在需要的事务中编写事务逻辑，TCC模式是自主实现的，每个要运用TCC模式的微服务都要编写实现类代码。TCC模式可以与AT、XA等模式混用。
@Service
@Slf4j
public class AccountTCCServiceImpl implements AccountTCCService {
@Autowired
private AccountMapper accountMapper;
@Autowired
private AccountFreezeMapper freezeMapper;
@Override
@Transactional
public void deduct(String userId, int money) {
// 获取全局事务id
String xid = RootContext.getXID();
// 防止业务悬挂
// 判断freeze里面是否有冻结记录，如果有证明Cancel已经执行过了
AccountFreeze oldFreeze = freezeMapper.selectById(xid);
if (oldFreeze != null){
return;
}
// 扣减余额
accountMapper.deduct(userId, money);
// 记录冻结金额
AccountFreeze freeze = new AccountFreeze();
freeze.setUserId(userId);
freeze.setFreezeMoney(money);
freeze.setState(AccountFreeze.State.TRY);
freeze.setXid(xid);
freezeMapper.insert(freeze);
}
@Override
public boolean confirm(BusinessActionContext ctx) {
// 查询全局事务id
String xid = ctx.getXid();
// 根据id删除冻结记录
int count = freezeMapper.deleteById(xid);
return count == 1;
}
@Override
public boolean cancel(BusinessActionContext ctx) {
// 获取全局事务id
String xid = ctx.getXid();
// 查询冻结记录
AccountFreeze freeze = freezeMapper.selectById(xid);
// 空回滚判断，判断freeze是否为null，为null证明try没执行，需要空回滚
if(freeze == null){
// 没执行try，需要空回滚
freeze = new AccountFreeze();
freeze.setFreezeMoney(0);
String userId = ctx.getActionContext("userId").toString();
freeze.setUserId(userId);
freeze.setXid(xid);
freeze.setState(AccountFreeze.State.CANCEL);
freezeMapper.insert(freeze);
return true;
}
// 幂等处理，避免多次调用cancel
if (freeze.getState() == AccountFreeze.State.CANCEL){
return true;
}
// 恢复可用金额
accountMapper.refund(freeze.getUserId(), freeze.getFreezeMoney());
// 将冻结金额清零，状态改为CANCEL
freeze.setState(AccountFreeze.State.CANCEL);
freeze.setFreezeMoney(0);
int count = freezeMapper.updateById(freeze);
return count == 1;
}
}
4.4.SAGA模式
Saga 模式是 Seata 即将开源的长事务解决方案，将由蚂蚁金服主要贡献。
其理论基础是Hector & Kenneth 在1987年发表的论文Sagas。
Seata官网对于Saga的指南：https://seata.io/zh-cn/docs/user/saga.html
4.4.1.原理
在 Saga 模式下，分布式事务内有多个参与者，每一个参与者都是一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作。
分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会去退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。
Saga也分为两个阶段：
-
一阶段：直接提交本地事务
-
二阶段：成功则什么都不做；失败则通过编写补偿业务来回滚
4.4.2.优缺点
优点：
-
事务参与者可以基于事件驱动实现异步调用，吞吐高
-
一阶段直接提交事务，无锁，性能好
-
不用编写TCC中的三个阶段，实现简单
缺点：
-
软状态持续时间不确定，时效性差
-
没有锁，没有事务隔离，会有脏写
seata四种模式对比
四、高可用和异地容灾
部署多个集群，当某一集群出现故障时实现更新切换到另一集群
模拟实现
-
搭建两台不同集群的seata的tc服务节点
-
将事务组的配置映射到nacos中，利用nacos实现配置的热更新
-
配置微服务application.yml文件，读取nacos配置
-
利用nacos配置修改集群映射的配置，模拟热更新
1.模拟异地容灾的TC集群
计划启动两台seata的tc服务节点：
| 节点名称 | ip地址 | 端口号 | 集群名称 |
|---|---|---|---|
| seata | 127.0.0.1 | 8091 | SH |
| seata2 | 127.0.0.1 | 8092 | HZ |
之前我们已经启动了一台seata服务，端口是8091，集群名为SH。
现在，将seata目录复制一份，起名为seata2
修改seata2/conf/registry.conf内容如下：
registry {
# tc服务的注册中心类，这里选择nacos，也可以是eureka、zookeeper等
type = "nacos"
nacos {
# seata tc 服务注册到 nacos的服务名称，可以自定义
application = "seata-tc-server"
serverAddr = "127.0.0.1:8848"
group = "DEFAULT_GROUP"
namespace = ""
cluster = "HZ"
username = "nacos"
password = "nacos"
}
}
config {
# 读取tc服务端的配置文件的方式，这里是从nacos配置中心读取，这样如果tc是集群，可以共享配置
type = "nacos"
# 配置nacos地址等信息
nacos {
serverAddr = "127.0.0.1:8848"
namespace = ""
group = "SEATA_GROUP"
username = "nacos"
password = "nacos"
dataId = "seataServer.properties"
}
}
进入seata2/bin目录，然后运行命令：
seata-server.bat -p 8092
打开nacos控制台，查看服务列表：
点进详情查看：
2.将事务组映射配置到nacos
接下来，我们需要将tx-service-group与cluster的映射关系都配置到nacos配置中心。
新建一个配置：
配置的内容如下：
# 事务组映射关系 service.vgroupMapping.seata-demo=SH service.enableDegrade=false service.disableGlobalTransaction=false # 与TC服务的通信配置 transport.type=TCP transport.server=NIO transport.heartbeat=true transport.enableClientBatchSendRequest=false transport.threadFactory.bossThreadPrefix=NettyBoss transport.threadFactory.workerThreadPrefix=NettyServerNIOWorker transport.threadFactory.serverExecutorThreadPrefix=NettyServerBizHandler transport.threadFactory.shareBossWorker=false transport.threadFactory.clientSelectorThreadPrefix=NettyClientSelector transport.threadFactory.clientSelectorThreadSize=1 transport.threadFactory.clientWorkerThreadPrefix=NettyClientWorkerThread transport.threadFactory.bossThreadSize=1 transport.threadFactory.workerThreadSize=default transport.shutdown.wait=3 # RM配置 client.rm.asyncCommitBufferLimit=10000 client.rm.lock.retryInterval=10 client.rm.lock.retryTimes=30 client.rm.lock.retryPolicyBranchRollbackOnConflict=true client.rm.reportRetryCount=5 client.rm.tableMetaCheckEnable=false client.rm.tableMetaCheckerInterval=60000 client.rm.sqlParserType=druid client.rm.reportSuccessEnable=false client.rm.sagaBranchRegisterEnable=false # TM配置 client.tm.commitRetryCount=5 client.tm.rollbackRetryCount=5 client.tm.defaultGlobalTransactionTimeout=60000 client.tm.degradeCheck=false client.tm.degradeCheckAllowTimes=10 client.tm.degradeCheckPeriod=2000 # undo日志配置 client.undo.dataValidation=true client.undo.logSerialization=jackson client.undo.onlyCareUpdateColumns=true client.undo.logTable=undo_log client.undo.compress.enable=true client.undo.compress.type=zip client.undo.compress.threshold=64k client.log.exceptionRate=100
3.微服务读取nacos配置
接下来，需要修改每一个微服务的application.yml文件，让微服务读取nacos中的client.properties文件。注意配置文件中的 group: SEATA_GROUP和data-id: client.properties的名称要与nacos中添加的完全一致，此外之前在application.yml文件中配置的集群映射可删可不删。
seata:
config:
type: nacos
nacos:
server-addr: 127.0.0.1:8848
username: nacos
password: nacos
group: SEATA_GROUP
data-id: client.properties
重启微服务，现在微服务到底是连接tc的SH集群，还是tc的HZ集群，都统一由nacos的client.properties来决定了。
4、模拟现象
在nacos的client.properties文件中修改集群名称，观察修改前后seata2终端日志的输出变化，判断是否更新成功。
1656
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
