分布式事务Seata

分布式事务解决方案-Seata

1 本地事务简介

本地事务也称为数据库事务传统事务(相对于分布式事务而言)。这一类事务是基于单个服务单一数据库访问的事务。

举例:电商系统的下单业务(生成订单、扣减库存、扣减余额)

image-20221125094822096

对应的伪代码:

image-20221125100027321

2 分布式事务概述

2.1 分布式事务简介

概述:分布式事务指的是组成业务逻辑单元的多个操作位于不同的服务上或者访问不同的数据库节点,分布式事务需要保证这些操作要么全部成功,要么全部失败。

如下图所示:

image-20221125101335217

对应的伪代码:

image-20221125102544329

2.2 分布式事务演示

本章通过一个案例来演示一下分布式系统下所出现的事务问题。

2.2.1 数据库环境准备

导入课程资料中的如下数据库脚本:

image-20240228215657915

2.2.2 基础工程环境准备

导入课前资料提供的微服务(seata-parent)

导入完毕以后的微服务结果如下所示:

image-20240228230554975

工程介绍:

parent: 父工程,负责管理项目依赖

  • business:业务服务,提供整个业务操作的入口接口
  • item:库存微服务
  • order:订单微服务
  • user:账户微服务
  • api:提供fegin接口,用于实现远程调用

服务之间的调用流程说明:

image-20221125110538446

注意:

1、每一个微服务都需要注册到注册中心中,在每一个微服务的的bootstrap.properties文件中更改注册中心地址

2、在nacos配置中心中添加对应微服务的配置信息,如下所示

# business-dev.yaml
server:
  port: 18081

spring:
  application:
    name: business
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://192.168.188.128:3306/seata-business?useUnicode=true&characterEncoding=UTF-8&serverTimezone=Asia/Shanghai
    username: root
    password: 1234

# item-dev.yaml
server:
  port: 18082

spring:
  application:
    name: item
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://192.168.188.128:3306/seata-item?useUnicode=true&characterEncoding=UTF-8&serverTimezone=Asia/Shanghai
    username: root
    password: 1234

# order-dev.yaml
server:
  port: 18083

spring:
  application:
    name: order
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://192.168.188.128:3306/seata-order?useUnicode=true&characterEncoding=UTF-8&serverTimezone=Asia/Shanghai
    username: root
    password: 1234
    
# user-dev.yaml
server:
  port: 18084

spring:
  application:
    name: user
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://192.168.188.128:3306/seata-user?useUnicode=true&characterEncoding=UTF-8&serverTimezone=Asia/Shanghai
    username: root
    password: 1234

2.2.3 基础代码测试

启动微服务进行测试

通过postman进行测试,测试地址:http://localhost:18081/addorder

正常测试

image-20221125111201280

查看数据库表变化:订单生成、库存扣减、账户余额扣减、business日志数据记录

异常测试

将user服务中的UserInfoServiceImpl#decrMoney方法中的如下注释放开,手动模拟异常。

image-20240303090151820

查询数据库表变化:订单生成、库存扣减,但是账户余额没有扣减,并且business日志数据没有记录。

3 理论基础

解决分布式事务问题,需要一些分布式系统的基础知识作为理论指导。

3.1 CAP定理

3.1.1 CAP定理结论

1998年,加州大学的计算机科学家 Eric Brewer 提出,分布式系统有三个指标。

1、Consistency(一致性)

2、Availability(可用性)

3、Partition tolerance (分区容错性)

image-20221125112635941

它们的第一个字母分别是 C、A、P。

Eric Brewer 说,这三个指标不可能同时做到。这个结论就叫做 CAP 定理。

3.1.2 一致性

Consistency(一致性):用户访问分布式系统中的任意节点,得到的数据必须一致。

比如现在包含两个节点,其中的初始数据是一致的:

image-20221125112748526

当我们修改其中一个节点的数据时,两者的数据产生了差异:

image-20221125112820436

要想保住一致性,就必须实现node01 到 node02的数据同步:

image-20221125112850389

3.1.2 可用性

Availability (可用性):用户访问集群中的任意健康节点,必须能得到响应,而不是超时或拒绝。

如图,有三个节点的集群,访问任何一个都可以及时得到响应:

image-20221125112939740

当有部分节点因为网络故障或其它原因无法访问时,代表节点不可用:

image-20221125113016779

3.1.3 分区容错

Partition(分区):因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接,形成独立分区。

image-20221125113057067

Tolerance(容错):在集群出现分区时,整个系统也要持续对外提供服务

在分布式系统中,系统间的网络不能100%保证健康,一定会有故障的时候,而服务有必须对外保证服务。因此Partition Tolerance不可避免。当节点

接收到新的数据变更时,就会出现问题了:

image-20221125113243045

如果此时要保证一致性,就必须等待网络恢复,完成数据同步后,整个集群才对外提供服务,服务处于阻塞状态,不可用。

如果此时要保证可用性,就不能等待网络恢复,那node01、node02与node03之间就会出现数据不一致。

也就是说,在P一定会出现的情况下,A和C之间只能实现一个。

注意:在CAP定理中一致性强调的是强一致性

3.2 BASE理论

BASE理论是对CAP的一种补充,包含三个思想:

1、Basically Available (基本可用):分布式系统在出现故障时,允许损失部分可用性,即保证核心可用。

2、Soft State(软状态):在一定时间内,允许出现中间状态,比如临时的不一致状态。

3、Eventually Consistent(最终一致性):虽然无法保证强一致性,但是在软状态结束后,最终达到数据一致。

4 初识Seata

4.1 Seata简介

Seata是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。致力于提供高性能和简单易用的分布式事务服务,为用户打造一站式的分布式解决方案。

官网地址:https://seata.io/zh-cn/,其中的文档、播客中提供了大量的使用说明、源码分析。

image-20240303090503089

4.2 Seata架构

基础概念:

分支事务:每一个业务系统的事务

全局事务:多个有关联的各个分支事务组成在一起

Seata事务管理中有三个重要的角色:

1、TC (Transaction Coordinator) - 事务协调者:维护全局和分支事务的状态,驱动全局事务提交或回滚。

2、TM (Transaction Manager) - 事务管理器:定义全局事务的范围:开始全局事务、提交或回滚全局事务。

3、RM (Resource Manager) - 资源管理器:管理分支事务处理的资源,与TC交谈以注册分支事务和报告分支事务的状态,并驱动分支事务提交或回滚。

工作流程如下图所示:

image-20221125115827929

1、由TM注册全局事务到TC

2、TC服务器会返回xid(本次全局事务的id),这个xid会随着微服务的调用一并传递下去

3、注册分支事务,通过RM注册分支事务到TC

4、各个分支事务开始执行业务SQL,并由RM报告每一个分支事务的执行状态到TC

5、当全局事务结束以后(各个分支事务执行完成),TC会进行分支事务状态的统计,然后在通过RM进行分支事务的回滚或者提交

Seata基于上述架构提供了常见的三种不同的分布式事务解决方案:

1、XA模式:强一致性分阶段事务模式,牺牲了一定的可用性,无业务侵入

2、AT模式:最终一致的分阶段事务模式,无业务侵入,也是Seata的默认模式

3、TCC模式:最终一致的分阶段事务模式,有业务侵入

无论哪种方案,都离不开TC,也就是事务的协调者。

5 XA模式

5.1 部署TC服务

具体步骤如下所示:

1、下载seata的tc服务端

首先我们要下载seata-server包,地址在http😕/seata.io/zh-cn/blog/download.html 当然,课程资料也准备好了:seata-server-2.0.0.zip

2、安装seata的tc服务端

在非中文目录解压缩这个zip包,其目录结构如下:

image-20240303103547860

3、修改config/application.yml文件

server:
  port: 7091

spring:
  application:
    name: seata-server

logging:
  config: classpath:logback-spring.xml
  file:
    path: ${log.home:${user.home}/logs/seata}
  extend:
    logstash-appender:
      destination: 127.0.0.1:4560
    kafka-appender:
      bootstrap-servers: 127.0.0.1:9092
      topic: logback_to_logstash
# 配置seata后台管理系统的访问用户名和密码
console:
  user:
    username: seata
    password: seata
seata:
  config:
    # support: nacos, consul, apollo, zk, etcd3
    type: nacos
    nacos:
      server-addr: 192.168.188.128:8848
      namespace:
      group: SEATA_GROUP
      username:
      password:
      context-path:
      data-id: seataServer.properties
  registry:
    # support: nacos, eureka, redis, zk, consul, etcd3, sofa
    type: nacos
    nacos:
      application: seata-server
      server-addr: 192.168.188.128:8848
      group: SEATA_GROUP
      namespace:
      cluster: default
      username:
      password:
      context-path:
  security:
    secretKey: "seata"
    tokenValidityInMilliseconds: 1000000000
  #store:
    # support: file 、 db 、 redis 、 raft
    # mode: file
  #  server:
  #    service-port: 8091 #If not configured, the default is '${server.port} + 1000'

4、Nacos添加配置 seataServer.properties , 注意:组名为SEATA_GROUP,修改其中的数据库信息

transport.type=TCP
transport.server=NIO
transport.heartbeat=true
transport.enableTmClientBatchSendRequest=false
transport.enableRmClientBatchSendRequest=true
transport.enableTcServerBatchSendResponse=false
transport.rpcRmRequestTimeout=30000
transport.rpcTmRequestTimeout=30000
transport.rpcTcRequestTimeout=30000
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
transport.serialization=seata
transport.compressor=none


service.vgroupMapping.default_tx_group=default
service.default.grouplist=127.0.0.1:8091
service.enableDegrade=false
service.disableGlobalTransaction=false

client.metadataMaxAgeMs=30000
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=true
client.rm.tableMetaCheckerInterval=60000
client.rm.sqlParserType=druid
client.rm.reportSuccessEnable=false
client.rm.sagaBranchRegisterEnable=false
client.rm.sagaJsonParser=fastjson
client.rm.tccActionInterceptorOrder=-2147482648
client.rm.sqlParserType=druid
client.tm.commitRetryCount=5
client.tm.rollbackRetryCount=5
client.tm.defaultGlobalTransactionTimeout=60000
client.tm.degradeCheck=false
client.tm.degradeCheckAllowTimes=10
client.tm.degradeCheckPeriod=2000
client.tm.interceptorOrder=-2147482648
client.undo.dataValidation=true
client.undo.logSerialization=jackson
client.undo.onlyCareUpdateColumns=true
server.undo.logSaveDays=7
server.undo.logDeletePeriod=86400000
client.undo.logTable=undo_log
client.undo.compress.enable=true
client.undo.compress.type=zip
client.undo.compress.threshold=64k
tcc.fence.logTableName=tcc_fence_log
tcc.fence.cleanPeriod=1h
tcc.contextJsonParserType=fastjson

log.exceptionRate=100

store.mode=db
store.lock.mode=db
store.session.mode=db
store.publicKey=

store.file.dir=file_store/data
store.file.maxBranchSessionSize=16384
store.file.maxGlobalSessionSize=512
store.file.fileWriteBufferCacheSize=16384
store.file.flushDiskMode=async
store.file.sessionReloadReadSize=100


store.db.datasource=druid
store.db.dbType=mysql
store.db.driverClassName=com.mysql.cj.jdbc.Driver
store.db.url=jdbc:mysql://192.168.188.128:3306/seata?useUnicode=true&rewriteBatchedStatements=true&useSSL=false
store.db.user=root
store.db.password=1234
store.db.minConn=5
store.db.maxConn=30
store.db.globalTable=global_table
store.db.branchTable=branch_table
store.db.distributedLockTable=distributed_lock
store.db.queryLimit=100
store.db.lockTable=lock_table
store.db.maxWait=5000


store.redis.mode=single
store.redis.type=pipeline
store.redis.single.host=127.0.0.1
store.redis.single.port=6379
store.redis.sentinel.masterName=
store.redis.sentinel.sentinelHosts=
store.redis.sentinel.sentinelPassword=
store.redis.maxConn=10
store.redis.minConn=1
store.redis.maxTotal=100
store.redis.database=0
store.redis.password=
store.redis.queryLimit=100

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.distributedLockExpireTime=10000
server.session.branchAsyncQueueSize=5000
server.session.enableBranchAsyncRemove=false
server.enableParallelRequestHandle=true
server.enableParallelHandleBranch=false

server.raft.cluster=127.0.0.1:7091,127.0.0.1:7092,127.0.0.1:7093
server.raft.snapshotInterval=600
server.raft.applyBatch=32
server.raft.maxAppendBufferSize=262144
server.raft.maxReplicatorInflightMsgs=256
server.raft.disruptorBufferSize=16384
server.raft.electionTimeoutMs=2000
server.raft.reporterEnabled=false
server.raft.reporterInitialDelay=60
server.raft.serialization=jackson
server.raft.compressor=none
server.raft.sync=true

metrics.enabled=false
metrics.registryType=compact
metrics.exporterList=prometheus
metrics.exporterPrometheusPort=9898

5、创建数据库表

特别注意:tc服务在管理分布式事务时,需要记录事务相关数据到数据库中,你需要提前创建好这些表。

新建一个名为seata的数据库,运行script\server\db\mysql.sql脚本文件。

6、本地java环境改成 8 , 17测试有问题,暂且不能全面支持

7、启动TC服务

进入bin目录,运行其中的seata-server.bat即可:

image-20240303111858761

启动成功后,seata-server应该已经注册到nacos注册中心了。

打开浏览器,访问nacos地址可以看到seata-tc-server的信息:

image-20240303120751147

打开浏览器,访问seata后台管理系统。地址:http://localhost:7091,用户名/密码: seata/seata

5.2 微服务集成seata

1、在微服务(api)中引入seata依赖:

<!--Seata依赖  -->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
    <exclusions>
        <exclusion>
            <groupId>io.seata</groupId>
            <artifactId>seata-spring-boot-starter</artifactId>
        </exclusion>
    </exclusions>
</dependency>

<!--使用2.0.0的seata的版本-->
<dependency>
    <groupId>io.seata</groupId>
    <artifactId>seata-spring-boot-starter</artifactId>
</dependency>

2、在nacos配置中心上添加seata的tc服务的公共配置:data-id=seata-common.yaml group=SEATA_GROUP

内容如下所示:

seata:
  # 配置seata-server在nacos注册中心上的信息
  registry:
    type: nacos
    nacos:
      namespace:
      group: SEATA_GROUP
      application: seata-server
      server-addr: 192.168.188.128:8848
  # 配置事务组的名称,需要和seata服务端的配置保持一致
  tx-service-group: default_tx_group
  service:
    vgroup-mapping:
      default_tx_group: default
  data-source-proxy-mode: XA   # 配置事务管理模式为xa模式

3、在每一个业务为服务端的bootstrap.properties添加加载seata-common.yaml的共享配置

spring.cloud.nacos.config.shared-configs[0].data-id=seata-common.yaml
spring.cloud.nacos.config.shared-configs[0].group=SEATA_GROUP

4、@GlobalTransactional

在BusinessServiceImpl的add方法上添加@GlobalTransactional注解,声明当前方法是一个全局事务方法。

5、重启微服务测试

重启微服务,观察TC服务器控制台日志输出:

image-20240303154147790

4个微服务已经集成到TC服务器中了。

5.3 XA原理

5.3.1 XA简介

XA规范是X/Open 组织定义的分布式事务处理(DTP,Distributed Transaction Processing)标准。

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

目前,几乎所有主流的数据库(MySQL、Oracle)都对 XA 规范 提供了支持。

5.3.2 工作原理

image-20221125131415448

工作流程如下所示:

RM一阶段的工作

1、注册分支事务到TC

2、执行分支业务sql但不提交

3、报告执行状态到TC

TC二阶段的工作:TC检测各分支事务执行状态

a.如果都成功,通知所有RM提交事务

b.如果有失败,通知所有RM回滚事务

RM二阶段的工作:接收TC指令,提交或回滚事务

5.3.3 优缺点

XA模式的优点是什么?

1、业务无侵入,不给应用设计和开发带来额外负担。

2、事务的强一致性(各个分支事务一起提交或回滚)

3、数据库的支持广泛:XA 协议被主流关系型数据库广泛支持,不需要额外的适配即可使用。

XA模式的缺点是什么?

XA prepare后(RM一阶段的工作完成后),分支事务进入阻塞阶段,收到XA commit 或 XA rollback 前必须阻塞等待。

事务资源长时间得不到释放,锁定周期长,而且在应用层上面无法干预,性能相对较差

6 AT模式

AT模式同样是分阶段提交的事务模型,不过缺弥补了XA模型中资源锁定周期过长的缺陷。

6.1 AT实战

更改nacos中seata-common.yaml的配置,如下所示:

seata:
  data-source-proxy-mode: AT          # 使用Seata框架的AT模式,默认是AT模式

重启服务进行测试。

6.2 原理介绍

AT模式的工作流程如下图所示:

image-20221125132507850

工作流程如下所示:

阶段一RM的工作:

1、注册分支事务

2、记录undo-log(数据快照:记录某一时刻数据的状态)

3、执行业务sql并提交

4、报告事务状态

阶段二提交时RM的工作:删除undo-log即可

阶段二回滚时RM的工作:根据undo-log恢复数据到更新前

6.3 流程梳理

我们用一个真实的业务来梳理下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检查分支事务状态

​ 2.1 如果都成功,则立即删除快照

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

6.4 AT与XA的区别

简述AT模式与XA模式最大的区别是什么?

1、XA模式一阶段不提交事务,锁定资源;AT模式一阶段直接提交,不锁定资源。

2、XA模式依赖数据库机制实现回滚;AT模式利用数据快照(undo-log)实现数据回滚。

3、XA模式强一致;AT模式最终一致

7 TCC模式

7.1 TCC模式概述

TCC模式与AT模式非常相似,每阶段都是独立事务,不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法:

1、Try:资源的检测和预留;

2、Confirm:完成资源操作业务;要求 Try 成功 Confirm 一定要能成功。

3、Cancel:预留资源释放,可以理解为try的反向操作。

7.2 流程分析

举例,一个扣减用户余额的业务。假设账户A原来余额是100,需要余额扣减30元。

阶段一( Try ):检查余额是否充足,如果充足则冻结金额增加30元,可用余额扣除30

初识余额:

image-20221125135802536 余额充足,可以冻结:

image-20221125135822734

此时,总金额 = 冻结金额 + 可用金额,数量依然是100不变。事务直接提交无需等待其它事务。

阶段二(Confirm):假如要提交(Confirm),则冻结金额扣减30

确认可以提交,不过之前可用金额已经扣减过了,这里只要清除冻结金额就好了:

image-20221125135929865

此时,总金额 = 冻结金额 + 可用金额 = 0 + 70 = 70元

阶段二(Canncel):如果要回滚(Cancel),则冻结金额扣减30,可用余额增加30

需要回滚,那么就要释放冻结金额,恢复可用金额:

image-20221125135958070

7.3 原理介绍

工作模式如下图所示:

image-20221125140203962

7.4 优缺点

TCC的优点是什么?

  • 一阶段完成直接提交事务,释放数据库资源,性能好
  • 相比AT模型,无需生成快照
  • 不依赖数据库事务,而是依赖补偿操作,可以用于非事务型数据库

TCC的缺点是什么?

  • 有代码侵入,需要人为编写try、Confirm和Cancel接口,太麻烦
  • 软状态,事务是最终一致

7.5 代码实现

7.5.1 数据库表创建

在seata-user数据库中定义一张用于进行资源预留的表:

CREATE TABLE `account_freeze_info` (
  `xid` varchar(128) NOT NULL,
  `userId` varchar(255) DEFAULT NULL COMMENT '用户id',
  `freezeMoney` int(11) DEFAULT NULL COMMENT '冻结金额',
  `state` int(1) DEFAULT NULL COMMENT '事务状态,0:try,1:confirm,2:cancel',
  PRIMARY KEY (`xid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

字段说明:

1、xid:是全局事务id

2、freeze_money:用来记录用户冻结金额

3、state:用来记录事务状态

7.5.2 创建实体类

@Data
@TableName(value="account_freeze_info")
public class AccountFreeze {

    @TableId(value = "xid" , type = IdType.INPUT)
    private String xid ;

    @TableField(value = "userId")
    private String userId ;

    @TableField(value = "freezeMoney")
    private Integer freezeMoney ;

    @TableField(value = "state")
    private Integer state ;

}

7.5.3 编写Mapper接口

public interface AccountFreezeMapper extends BaseMapper<AccountFreeze> {
    
}

7.5.4 TCC接口

在service包下创建。

@LocalTCC
public interface AccountTCCService {

    @TwoPhaseBusinessAction(name = "deduct", commitMethod = "confirm", rollbackMethod = "cancel")
    void deduct(@BusinessActionContextParameter(paramName = "account") String account,
                @BusinessActionContextParameter(paramName = "money")int money);

    boolean confirm(BusinessActionContext ctx);
    boolean cancel(BusinessActionContext ctx);

}

7.5.5 TCC接口实现类

@Service
public class AccountTCCServiceImpl implements AccountTCCService {

    @Autowired
    private AccountFreezeMapper accountFreezeMapper ;

    @Autowired
    private UserInfoMapper userInfoMapper ;

    @Override
    public void deduct(String account, int money) {

        // 可用余额进行校验
        UserInfo userInfo = userInfoMapper.selectById(account);
        if(userInfo.getMoney() < money) {
            throw new RuntimeException("账户余额不足") ;
        }

        // 扣减可用余额
        userInfo.setMoney(userInfo.getMoney() - money);
        userInfoMapper.updateById(userInfo);

        // 记录冻结金额
        AccountFreeze accountFreeze = new AccountFreeze() ;
        accountFreeze.setFreezeMoney(money);
        accountFreeze.setState(0);
        accountFreeze.setUserId(account);

        // 获取事务id
        String xid = RootContext.getXID();
        accountFreeze.setXid(xid);
        accountFreezeMapper.insert(accountFreeze) ;

    }

    @Override
    public boolean confirm(BusinessActionContext ctx) {
        String xid = ctx.getXid();                                  // 获取事务的id
        int count = accountFreezeMapper.deleteById(xid);    // 删除冻结记录
        return count == 1;
    }

    @Override
    public boolean cancel(BusinessActionContext ctx) {

        // 查询冻结记录
        String xid = ctx.getXid();
        AccountFreeze accountFreeze = accountFreezeMapper.selectById(xid);
        
        if(accountFreeze == null) {         // 如果账户余额不足,那么此时没有执行try操作,就不用进行回滚
            return true ;
        }

        // 恢复可用余额
        String userId = accountFreeze.getUserId();
        UserInfo userInfo = userInfoMapper.selectById(userId);
        userInfo.setMoney(userInfo.getMoney() + accountFreeze.getFreezeMoney());
        userInfoMapper.updateById(userInfo) ;

        // 将冻结金额清零,状态更改为cancel
        accountFreeze.setFreezeMoney(0);
        accountFreeze.setState(2);
        int count = accountFreezeMapper.updateById(accountFreeze);
        return count == 1;
        
    }

}

7.5.6 修改UserInfoController

在UserInfoController中注入AccountTCCService接口,完成业务处理:

@RestController
@RequestMapping("/userInfo")
@CrossOrigin
public class UserInfoController {

    @Autowired
    private AccountTCCService accountTCCService;

    /***
     * 账户余额递减
     * @param username
     * @param money
     */
    @PostMapping(value = "/add")
    public String decrMoney(@RequestParam(value = "username") String username, @RequestParam(value = "money") int money){
        accountTCCService.deduct(username,money);
        return "success";
    }

}
posted @   LilyFlower  阅读(10)  评论(0编辑  收藏  举报
编辑推荐:
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· AI与.NET技术实操系列:向量存储与相似性搜索在 .NET 中的实现
· 基于Microsoft.Extensions.AI核心库实现RAG应用
· Linux系列:如何用heaptrack跟踪.NET程序的非托管内存泄露
阅读排行:
· TypeScript + Deepseek 打造卜卦网站:技术与玄学的结合
· 阿里巴巴 QwQ-32B真的超越了 DeepSeek R-1吗?
· 【译】Visual Studio 中新的强大生产力特性
· 10年+ .NET Coder 心语 ── 封装的思维:从隐藏、稳定开始理解其本质意义
· 【设计模式】告别冗长if-else语句:使用策略模式优化代码结构
点击右上角即可分享
微信分享提示