Seata,之前叫做Fescar,是一个开源的分布式事务解决方案,它主要致力于提供高效和简单的分布式事务服务。Seata主要用于解决微服务架构下的数据一致性问题。
Seata 的基本原理是基于两阶段提交 (2PC) 以及三阶段提交 (3PC),但它对这些经典的分布式事务协议进行了扩展和优化,以适应微服务场景
本地事务,也就是传统的单机事务。在传统数据库事务中,必须要满足四个原则:
分布式事务,就是指不是在单个服务或单个数据库架构下,产生的事务,例如:
在数据库水平拆分、服务垂直拆分之后,一个业务操作通常要跨多个数据库、服务才能完成。例如电商行业中比较常见的下单付款案例,包括下面几个行为:
完成上面的操作需要访问三个不同的微服务和三个不同的数据库。
订单的创建、库存的扣减、账户扣款在每一个服务和数据库内是一个本地事务,可以保证ACID原则。
但是当我们把三件事情看做一个"业务",要满足保证“业务”的原子性,要么所有操作全部成功,要么全部失败,不允许出现部分成功部分失败的现象,这就是分布式系统下的事务了。
此时ACID难以满足,这是分布式事务要解决的问题
我们通过一个案例来演示分布式事务的问题:
1)创建数据库,:
2)假设有三个微服务:
微服务结构如下:
其中:
seata-demo:父工程,负责管理项目依赖
3)启动nacos、所有微服务
4)测试下单功能,发出Post请求:
请求如下:
curl --location --request POST 'http://localhost:8082/order?userId=user202103032042012&commodityCode=100202003032041&count=20&money=200'
业务整理lp:
对订单服务发起请求,由于订单服务里面包含其他的业务,数据库独立,订单业务又会通过feign去执行用户账户扣除和上商店库存扣除
如图:
其中传递了几个参数 用户id 和扣款项,以及库存 ,但是商店库存不够,所以返回异常
但是金额200 是已经被扣除了
这个时候就出现数据执行不同步的操作,并且因为不是一个数据库 没有办法回滚
测试发现,当库存不足时,如果余额已经扣减,并不会回滚,出现了分布式事务问题。
解决分布式事务问题,需要一些分布式系统的基础知识作为理论指导。
1998年,加州大学的计算机科学家 Eric Brewer 提出,分布式系统有三个指标。
- Consistency(一致性)
- Availability(可用性)
- Partition tolerance (分区容错性)
它们的第一个字母分别是 C、A、P。
Eric Brewer 说,这三个指标不可能同时做到。这个结论就叫做 CAP 定理。
Consistency(一致性):用户访问分布式系统中的任意节点,得到的数据必须一致。
比如现在包含两个节点,其中的初始数据是一致的:
当我们修改其中一个节点的数据时,两者的数据产生了差异:
要想保住一致性,就必须实现node01 到 node02的数据 同步:
Availability (可用性):用户访问集群中的任意健康节点,必须能得到响应,而不是超时或拒绝。
如图,有三个节点的集群,访问任何一个都可以及时得到响应:
当有部分节点因为网络故障或其它原因无法访问时,代表节点不可用:
Partition(分区):因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接,形成独立分区。
Tolerance(容错):在集群出现分区时,整个系统也要持续对外提供服务
在分布式系统中,系统间的网络不能100%保证健康,一定会有故障的时候,而服务有必须对外保证服务。因此Partition Tolerance不可避免。
当节点接收到新的数据变更时,就会出现问题了:
如果此时要保证一致性,就必须等待网络恢复,完成数据同步后,整个集群才对外提供服务,服务处于阻塞状态,不可用。
如果此时要保证可用性,就不能等待网络恢复,那node01、node02与node03之间就会出现数据不一致。
也就是说,在P(分区情况下)一定会出现的情况下,A和C之间只能实现一个。
BASE理论是对CAP的一种解决思路,包含三个思想:
分布式事务最大的问题是各个子事务的一致性问题,因此可以借鉴CAP定理和BASE理论,有两种解决思路:
AP模式:各子事务分别执行和提交,允许出现结果不一致,然后采用弥补措施恢复数据即可,实现最终一致。
CP模式:各个子事务执行后互相等待,同时提交,同时回滚,达成强一致。但事务等待过程中,处于弱可用状态。
但不管是哪一种模式,都需要在子系统事务之间互相通讯,协调事务状态,也就是需要一个事务协调者(TC):
这里的子系统事务,称为分支事务;有关联的各个分支事务在一起称为全局事务。
Seata是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。致力于提供高性能和简单易用的分布式事务服务,为用户打造一站式的分布式解决方案。
官网地址:http://seata.io/,其中的文档、播客中提供了大量的使用说明、源码分析。
Seata事务管理中有三个重要的角色:
TC (Transaction Coordinator) - **事务协调者:**维护全局和分支事务的状态,协调全局事务提交或回滚。
TM (Transaction Manager) - **事务管理器:**定义全局事务的范围、开始全局事务、提交或回滚全局事务。
RM (Resource Manager) - **资源管理器:**管理分支事务处理的资源,与TC交谈以注册分支事务和报告分支事务的状态,并驱动分支事务提交或回滚。
整体的架构如图:
Seata基于上述架构提供了四种不同的分布式事务解决方案:
无论哪种方案,都离不开TC,也就是事务的协调者。
1.首先我们要下载seata-server包,地址在http/seata.io/zh-cn/blog/download.html
2.修改配置文件config->registr.config
3.修改
registry代表的是注册中心把type(注册中心类型)修改为nacos nacos默认是下面的描述,如果不是就要自定义修改,其余修改为和nacos对应组,集群,namespace…
值得注意的是,配置文件也应该交给nacos管理 ,作为分布式中的一个微服务,应该把配置文件放在服务中 改为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 = ""
# 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的配置
在ncos上添加配置 文件id和注册配置文件上的一至
配置内容
# 数据存储方式,db代表数据库 还支持redisa 缓存保存
store.mode=db
store.db.datasource=druid
store.db.dbType=mysql
#sql8以上记得使用cj新驱动 并且设置时区&characterEncoding=UTF-8&serverTimezone=Asia/Shanghai
store.db.driverClassName=com.mysql.jdbc.Driver
store.db.url=jdbc:mysql://127.0.0.1:3306/seata_demo?useUnicode=true&rewriteBatchedStatements=true
store.db.user=root
store.db.password=111111
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
4.在配置文件中指定的数据库添加表 记录全局事务,分支事务,全局锁事务
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-server,找到解压文件的bin(执行目录) 点击批处理文件bat
打开游览器 访问nacos 发现其实已经启动成功了 nacos的高可用 ,如果担心一个服务挂了 可以启多个同名服务 ,这里seata服务也是一样的,这样nacos会根据健康状态选择,(水平扩展)
此时seata Tc服务已经注册
我们以order-service 订单服务进行演示(服务调用另外俩个服务开启事务)。
首先,在order-service中引入依赖:
<dependency>
<groupId>com.alibaba.cloudgroupId>
<artifactId>spring-cloud-starter-alibaba-seataartifactId>
<exclusions>
<exclusion>
<artifactId>seata-spring-boot-starterartifactId>
<groupId>io.seatagroupId>
exclusion>
exclusions>
dependency>
<dependency>
<groupId>io.seatagroupId>
<artifactId>seata-spring-boot-starterartifactId>
<version>${seata.version}version>
dependency>
在order-service中的application.yml中,配置TC服务信息,通过注册中心nacos,结合服务名称获取TC地址:
seata:
registry: # TC服务注册中心的配置,微服务根据这些信息去注册中心获取tc服务地址
type: nacos # 注册中心类型 nacos
nacos:
server-addr: 127.0.0.1:8848 # nacos地址
namespace: "" # namespace,默认为空 命名空间会进行隔离
group: DEFAULT_GROUP # 分组,默认是DEFAULT_GROUP
application: seata-tc-server # seata服务名称
username: nacos
password: nacos
tx-service-group: seata-demo # 事务组名称
service:
vgroup-mapping: # 事务组与cluster的映射关系 应该把集群配置到意思
seata-demo: default #关联的集群名
其中
Seata(分布式事务解决方案)中的配置文件中的事务组(tx-service-group)是用于标识事务组的名称。事务组用于将一组相关的业务服务划分为一个事务单元,以便协调它们的分布式事务。这个名称在Seata中是一个重要的标识,它用于唯一标识一个事务组。
Seata配置文件中,tx-service-group的值为seata-demo,这表示你的Seata实例将用于协调与名为seata-demo的事务组相关的业务服务的分布式事务。
关于配置文件中的vgroup-mapping部分,这是用于映射事务组与集群(Cluster)之间的关系。在分布式系统中,可以有多个不同的集群,用于提供不同的部署和容量选项。通过vgroup-mapping,你可以将事务组映射到特定的集群上。这对于在不同环境中(例如开发、测试、生产)使用不同的集群或配置选项非常有用。如果你没有显式地配置vgroup-mapping,Seata将使用默认的集群。
在配置文件中一定要详细写清楚服务的命名空间,处于哪个服务分组,又是哪个集群里面的
在Nacos中,有一些概念可以帮助你实现不同级别的服务隔离和路由。这包括Namespace、Group和Cluster。虽然它们有一些相似之处,但它们在用途和功能上是不同的:
Namespace主要用于环境隔离,Group用于对服务进行分组,而Cluster则用于实现负载均衡和故障隔离。它们在不同的层面提供了服务隔离和路由的功能,可以根据具体的需求来灵活配置。
微服务如何根据这些配置寻找TC的地址呢?
我们知道注册到Nacos中的微服务,确定一个具体实例需要四个信息:
以上四个信息,在刚才的yaml文件中都能找到:
namespace为空,就是默认的public
结合起来,TC服务的信息就是:public@DEFAULT_GROUP@seata-tc-server@SH,这样就能确定TC服务集群了。然后就可以去Nacos拉取对应的实例信息了。
其它两个微服务也都参考order-service的步骤来做,完全一样。
启动服务查看seata控制台 显示注册成功 并且有完整的注册名
下面我们就一起学习下Seata中的四种不同的事务模式。
XA 规范 是 X/Open 组织定义的分布式事务处理(DTP,Distributed Transaction Processing)标准,XA 规范 描述了全局的TM与局部的RM之间的接口,几乎所有主流的数据库都对 XA 规范 提供了支持。
XA是规范,目前主流数据库都实现了这种规范,实现的原理都是基于两阶段提交。
正常情况:
异常情况:
一阶段:
二阶段:
是一种强一致性的标准
Seata对原始的XA模式做了简单的封装和改造,以适应自己的事务模型,基本架构如图:
RM一阶段的工作:
① 注册分支事务到TC
② 执行分支业务sql但不提交
③ 报告执行状态到TC
TC二阶段的工作:
TC检测各分支事务执行状态
a.如果都成功,通知所有RM提交事务
b.如果有失败,通知所有RM回滚事务
RM二阶段的工作:
XA模式的优点是什么?
XA模式的缺点是什么?
Seata的starter已经完成了XA模式的自动装配,实现非常简单,步骤如下:
1)修改application.yml文件(每个参与事务的微服务),开启XA模式:
seata:
#对于datasource 进行拦截 数据库的事务交给seata的xa模式代理
data-source-proxy-mode: XA
2)给发起全局事务的入口方法(全局事务的入口 就类似微服务请求链中的第一个请求 a.getxx->b.creaxx->c.service 这里a服务的getxx就是该事务的全局请求 入口, 而事务就是服务链中第一个参生事务操作的就是入口) 添加@GlobalTransactional注解:
本例中是OrderServiceImpl中的create方法最先开启事务.
3)重启服务并测试
依旧是库存服务只有10 但是订单需要扣除20
此时成功,数据中没有执行sql操作 ,三个服务都保障了业务一致
查看被分支业务 之前账户服务是会被扣款成功的,现在日志报回滚log
重启order-service,再次测试,发现无论怎样,三个微服务都能成功回滚。
AT模式同样是分阶段提交的事务模型,不过缺弥补了XA模型中资源锁定周期过长的缺陷。
基本流程图:
阶段一RM的工作:
阶段二提交时RM的工作:
阶段二回滚时RM的工作:
事务执行成功 删除快照 事务执行失败 同一回复到快照
我们用一个真实的业务来梳理下AT模式的原理。
比如,现在又一个数据库表,记录用户余额:
id | money |
---|---|
1 | 100 |
其中一个分支业务要执行的SQL为:
update tb_account set money = money - 10 where id = 1
AT模式下,当前分支事务执行流程如下:
一阶段:
1)TM发起并注册全局事务到TC
2)TM调用分支事务
3)分支事务准备执行业务SQL
4)RM拦截业务SQL,根据where条件查询原始数据,形成快照。
{
"id": 1, "money": 100
}
5)RM执行业务SQL,提交本地事务,释放数据库锁。此时 money = 90
6)RM报告本地事务状态给TC
二阶段:
1)TM通知TC事务结束
2)TC检查分支事务状态
a)如果都成功,则立即删除快照
b)如果有分支事务失败,需要回滚。读取快照数据({"id": 1, "money": 100}
),将快照恢复到数据库。此时数据库再次恢复为100
流程图:
简述AT模式与XA模式最大的区别是什么?
在多线程并发访问AT模式的分布式事务时,有可能出现脏写问题,如图:
假如多个线程操作同一事务,其中一个线程先拿到数据锁执行完sql 提交事务以后释放锁,另一个线程就能拿到锁在进行一次sql执行,并且线程一刚好完at模式中有个事务失败需要回滚,这个时候数据就脏写了
解决思路就是引入了全局锁的概念。
在释放DB锁之前,先拿到全局锁。避免同一时刻有另外一个事务来操作当前数据。
AT模式的优点:
AT模式的缺点:
XA事务的强一致性是通过事务等待来实现的,分支事务等待所有事务完成才能进行提交,提交后才能释放锁sql锁,对性能一致处于消耗,AT模式是直接先进性提交 然后释放sql锁,最后靠全局锁来实现防止脏数据,且回复靠快照,无序等待事务链中所有数据。
AT模式中的快照生成、回滚等动作都是由框架自动完成,没有任何代码侵入,因此实现非常简单。
只不过,AT模式需要一个表来记录全局锁、另一张表来记录数据快照undo_log。
1)导入数据库表,记录全局锁
其中lock_table导入到TC服务关联的数据库,undo_log表导入到微服务关联的数据库:
/*
Navicat Premium Data Transfer
Source Server : local
Source Server Type : MySQL
Source Server Version : 50622
Source Host : localhost:3306
Source Schema : seata_demo
Target Server Type : MySQL
Target Server Version : 50622
File Encoding : 65001
Date: 20/06/2021 12:39:03
*/
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;
-- ----------------------------
-- Records of undo_log
-- ----------------------------
-- ----------------------------
-- Table structure for 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;
注意实际开发,seata的配置数据和实际开发的业务数据肯定不是在一个库,这里为了演示放在一个库
2)修改application.yml文件,将事务模式修改为AT模式即可:
seata:
data-source-proxy-mode: AT # 默认就是AT
3)重启服务并测试
此时创建了一个订单数据后,库存剩余8,monney剩下700
将测试参数数据刚好多一个
数据库无改变
库存服务应该粗库没有那么多,所以肯定无法提交事务报错
AT和X A比需要多添加俩张表,一张全局锁,一张快照表 ,其余大致相同
都是添加全局事务注解标记监控管理的事务入口,springcloud底层自动完成事务揽件监控,无序二次实现
TCC模式与AT模式非常相似,每阶段都是独立事务,不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法:
Try:资源的检测和预留;
Confirm:完成资源操作业务;要求 Try 成功 Confirm 一定要能成功。
Cancel:预留资源释放,可以理解为try的反向操作。
整个要点看完,发现并没有使用到锁的机制,这就使得这种模式对于性能省去了性能的消耗,适合对性能有要求的事务处理
举例,一个扣减用户余额的业务。假设账户A原来余额是100,需要余额扣减30元。
初识余额:
余额充足,可以冻结:
此时,总金额 = 冻结金额 + 可用金额,数量依然是100不变。事务直接提交无需等待其它事务。
确认可以提交,不过之前可用金额已经扣减过了,这里只要清除冻结金额就好了:
此时,总金额 = 冻结金额 + 可用金额 = 0 + 70 = 70元
需要回滚,那么就要释放冻结金额,恢复可用金额:
可以发现该模式和AT XA不同没有等待也没有全局锁和快照回复,有的是数据冻结然后进行操作的,如果需要回滚就根据log反向操作,无序等待
Seata中的TCC模型依然延续之前的事务架构,如图:
TCC模式的每个阶段是做什么的?
TCC的优点是什么?
TCC的缺点是什么?
当某分支事务的try阶段阻塞时,可能导致全局事务超时而触发二阶段的cancel操作。在未执行try操作时先执行了cancel操作,这时cancel不能做回滚(没有做资源预留),就是空回滚。
如图:
执行cancel操作时,应当判断try是否已经执行,如果尚未执行,则应该空回滚。
对于已经空回滚的业务,之前被阻塞的try操作恢复,继续执行try,就永远不可能confirm或cancel ,事务一直处于中间状态,这就是业务悬挂。
执行try操作时,应当判断cancel是否已经执行过了,如果已经执行,应当阻止空回滚后的try操作,避免悬挂 所以需要当这个时候的状态持久化在库中,给seata进行判断
解决空回滚和业务悬挂问题,必须要记录当前事务状态,是在try、还是cancel?
这里我们定义一张表:
CREATE TABLE `account_freeze_tbl` (
`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;
其中:
那此时,我们的业务开怎么做呢?
接下来,我们改造account-service,利用TCC实现余额扣减功能。
TCC的Try、Confirm、Cancel方法都需要在接口中基于注解来声明,
我们在account-service项目中的cn.itcast.account.service
包中新建一个接口,声明TCC三个接口:
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
public interface AccountTCCService {
/* Try逻辑,@TwoPhaseBusinessAction中的name属性要与当前方法名一致,用于指定Try逻辑对应的方法 */
@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);
}
在account-service服务中的cn.itcast.account.service.impl
包下新建一个类,实现TCC业务:
@Service
@Slf4j
public class AccountTCCServiceImpl implements AccountTCCService {
@Autowired
private AccountMapper accountMapper;
@Autowired
private AccountFreezeMapper freezeMapper;
@Override
@Transactional
public void deduct(String userId, int money) {
// 0.获取事务id
String xid = RootContext.getXID();
// 获取到事务id或对冻结表进行查询,如果该事务已经执行过回滚
if (freezeMapper.selectById(xid) != null){
// 说明预留表有数据,之间做过预留操作或者回滚操作 直接拒绝在进行预留操作
return;
}
// 1.扣减可用余额
accountMapper.deduct(userId, money);
// 2.记录冻结金额,事务状态
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) {
// 1.获取事务id
String xid = ctx.getXid();
// 2.根据id删除冻结记录
int count = freezeMapper.deleteById(xid);
return count == 1;
}
@Override
public boolean cancel(BusinessActionContext ctx) {
// 0.查询冻结记录
String xid = ctx.getXid();
AccountFreeze freeze = freezeMapper.selectById(xid);
if (freeze == null) {
// 发现冻结表没有数据 说明没有执行try 进行冻结预留 进行空回滚
String userId = ctx.getActionContext("userId").toString();//获取用户id 之前植入的参数
freeze.setXid(xid);
freeze.setUserId(userId);
// 回滚中设置冻结数据为0
freeze.setFreezeMoney(0);
//设置状态
freeze.setState(AccountFreeze.State.CANCEL);
freezeMapper.insert(freeze);
return true;
}
//判断冻结数据状态 如果冻结预留表的记录是cancel 说明之前就已经回滚过一次了
if (freeze.getState() == AccountFreeze.State.CANCEL){
// 无序重复处理
return true;
}
// 1.恢复可用余额
accountMapper.refund(freeze.getUserId(), freeze.getFreezeMoney());
// 2.将冻结金额清零,状态改为CANCEL
freeze.setFreezeMoney(0);
freeze.setState(AccountFreeze.State.CANCEL);
int count = freezeMapper.updateById(freeze);
return count == 1;
}
}
其中对冻结表的mapper就是基础的Mpmapper
扣款的数据maper要做对应的扣除数据和恢复
/**
* @author 虎哥
*/
public interface AccountMapper extends BaseMapper<Account> {
@Update("update account_tbl set money = money - ${money} where user_id = #{userId}")
int deduct(@Param("userId") String userId, @Param("money") int money);
@Update("update account_tbl set money = money + ${money} where user_id = #{userId}")
int refund(@Param("userId") String userId, @Param("money") int money);
}
设置冻结表数据的状态是映射做的枚举
修改将controller中调用的service改为实现TCC模式的接口
配置文件中的代理模式可以不用改,改模式可以和其他模式混用,只是修改了其中一个业务还原的逻辑
TCC模式不涉及配置文件的修改,因为它是一种在应用程序代码级别实现的事务模式,与代理服务器或数据交换的配置无关。在TCC模式下,您需要编写适当的业务逻辑来实现"Try"、"Confirm"和"Cancel"阶段,以确保分布式事务的一致性。这与配置文件中的数据代理模式没有直接关联。
重启测试
先执行正常创建订单扣库存业务
发现成功
限制测试扣除超过本地数量的数据
通过日志可以知道虽然执行了扣款,但是最后进行了反向逻辑又加了回来,代替了以前的回滚逻辑
Saga 模式是 Seata 即将开源的长事务解决方案,将由蚂蚁金服主要贡献。
其理论基础是Hector & Kenneth 在1987年发表的论文Sagas。
Seata官网对于Saga的指南:https://seata.io/zh-cn/docs/user/saga.html
在 Saga 模式下,分布式事务内有多个参与者,每一个参与者都是一个冲正补偿服务,需要用户根据业务场景实现其正向操作和逆向回滚操作。
分布式事务执行过程中,依次执行各参与者的正向操作,如果所有正向操作均执行成功,那么分布式事务提交。如果任何一个正向操作执行失败,那么分布式事务会去退回去执行前面各参与者的逆向回滚操作,回滚已提交的参与者,使分布式事务回到初始状态。
Saga也分为两个阶段:
和tcc很想,但是TCC操作的是冻结的预留数据,这个是直接操作数据
优点:
缺点:
我们从以下几个方面来对比四种实现:
如图:
Seata的TC服务作为分布式事务核心,一定要保证集群的高可用性。
搭建TC服务集群非常简单,启动多个TC服务,注册到nacos即可。
但集群并不能确保100%安全,万一集群所在机房故障怎么办?所以如果要求较高,一般都会做异地多机房容灾。
比如一个TC集群在上海,另一个TC集群在杭州:
微服务基于事务组(tx-service-group)与TC集群的映射关系,来查找当前应该使用哪个TC集群。当SH集群故障时,只需要将vgroup-mapping中的映射关系改成HZ。则所有微服务就会切换到HZ的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控制台,查看服务列表:
点进详情查看:
接下来,我们需要将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
接下来,需要修改每一个微服务的application.yml文件,让微服务读取nacos中的client.properties文件:
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来决定了。