86 SpringCloud解决分布式事务

Posted 2023-05-02

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了86 SpringCloud解决分布式事务相关的知识，希望对你有一定的参考价值。

参考技术A 1，分布式事务产生的背景；
分情况而定。
1，在单体项目中，多个不同的业务逻辑都是在同一个数据源中心实现事务管理，是不存在分布式事务的问题。因为在同一个数据源的情况下都是采用事务管理器，相当于每个事务管理器对应一个数据源。
2，在单体项目中，有多个不同的数据源，每个数据源中都有自己独立的事务管理器，互不影响，那么这时候也会存在多数据源事务管理：解决方案jta+Atomikos
3，在分布式/微服务架构中。每个服务都有自己的本地的事务。每个服务本地事务互不影响，那么这时候也会存在分布式事务的问题。
分布式事务产生的背景：订单服务调用派单服务接口成功之后，可能会引发错误。
2pc3pc思想，实际上都是解决我们在分布式系统中，每个节点保证数据一致性问题。
事务的定义。
对我们业务逻辑可以实现提交或者是回滚，保证数据一致性的情况。所以，要么提交，要么回滚。
原子性a 要么提交要么回滚。
一致性 c
持久性d 事务一旦提交或者回滚后，不会再对该结果有任何的影响。
Base 与 cap理论。
1，cap定律
这个定理的内容是指的是在一个分布式系统中,Consistency（一致性），Availability（可用性），Partition tolerance(分区容错性)，二者不可兼容。
1，一致性（C）
在分布式系统中的所有数据备份，是在同一时刻是否同样的值，（等同于所有节点访问同一份最新的数据副本）
2，可用性 A
在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求（对数据更新具有高可用性）

3，分区容错性（p）形成脑裂问题：
以实际效果而言，分区相当于对通信的时限要求，系统如果不能再时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

4，总结下
以上可以知道分区容错性（P）主要代表网络波动产生的错误，这是不可以避免的，且这三个模式不可以兼得，所以目前就2种模式: cp和Ap模式。
其中cp表示遵循一致性的原则，但不能保证高可用性，其中zookeeper作为注册中心就是采用cp模式，因为zookeeper有过半节点不可以的话整个zookeeper将不可用。
AP表示遵循于可用性原则，例如Eureka作为注册中心用的是AP模式，因为其为去中心化，采用你中有我我中有你的相互注册方式，只要集群中有一个节点可以使用，整个eureka服务就是可用的，但可能会出现短暂的数据不一致问题。

Ap保证可用性：但是不能保证每个副本数据数据一致性，
cp保证数据一致性；如果有过半的zk节点宕机的情况下，不能保证可用性，但是必须保证每个副本节点之间数据一致性，比如zk。

Base理论：
Base是 Basically Available(基本可用)，Softstate(软状态)和Eventually consistent(最终一致性)三个短语的缩写。Base理论是对CAP定理逐步演化而来的，base理论核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式达到最终一致性。
1基本可用性；
基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性，注意：这绝不等于系统不可用。
比如：响应时间的损失，正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能顺利完成每一笔订单，但是在一些介入大促销购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能被引导在一个降级页面。
2，软状态。
软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，既允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

3，最终一致性
最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态，因此，最终一致性的本质需要系统保证数据能够达成一致，而不需要时时保证系统数据的强一致性。

2pc 与3pC
通过2pc和3pc 思想可以实现保证每个节点的数据一致性问题。

目前主流分布式解决框架
1，单体项目多数据源，可以jta+Atomilos；
2，基于Rabbitmq的形式解决最终一致性思想；
3，基于Rocketmq解决分布式事务，采用事务消息。
4，lcn采用lcn模式，假关闭连接
5，Alibaba的seata 背景强大，已经成为了主流。
以上适合于微服务架构中，不适合于和外部接口保证分布式事务问题。
6，跨语言的方式实现解决分布式事务问题。类似于支付宝回调方式。
2阶段提交协议基本概念。

2阶段提交协议基本概念：

俩阶段提交协议可以理解为2pc，也就是分为参与者和协调者，协调者会通过2次阶段实现数据最终一致性的
2pc和3pc 的区别就是解决参与者超时问题和多加了一层询问。保证了数据传输的可靠性。
简单的回顾下lcn解决分布式事务。

http://www.txlcn.org/zh-cn/ LCN并不生产事务，LCN只是本地事务的协调工

现在官网已经不维护呢，可以参考：GitEE

https://gitee.com/wangliang1991/tx-lcn?_from=gitee_search

默认密码为：codingapi

lcn基本实现的原理：
1，发起方与参与方都与我们的lcn保持长连接；
2，发起方调用接口前，先向lcn管理器中申请一个全局的事务分组id;
3,发起方调用接口的时候在请求头里传递事务分组id.
4,参与方获取到请求头中有事务分组的id的，则当前业务逻辑执行完实现假关闭，不会提交或者回滚当前事务，
5，发起方调用完接口后，如果出现异常的情况下，在通知事务协调者回滚事务，这时候事务协调则告诉给参与者回滚当前的事务。

lcn 解决分布式事务的原理：
角色划分
1，全局事务协调者（组长）；
2，发起方---调用接口者；
3，参与方---被别人调用接口
订单（发起方）调用派单（参与方）
1.发起方和参与方都会与我们的全局事务协调者保持长连接；

整合和源码解读

spring-boot 2.1.6.RELEASE+spring-cloud Greenwich.RELEASE +seata 1.4
pom如下：

file.conf

registry.conf:

yml配置：

添加 DataSourceConfiguration

其他模块参照此模块配置，
seata的registry.conf 和file.conf配置和项目配置一致。
添加全局事务：

https://gitee.com/lttwj/wj1/tree/master/seata/springcloud-seata

1,如何学会分析框架的源码？思想有哪些？
A： spring入口角度分析 springbean 生命周期ioc容器底层原理。
B. 报错日志法
2，seata 底层如何解决分布式事务的？
3，seata 如何生成全局xid
4,Seata如何生成前置和后置镜像。
5，seata 如何传递xid的
6， Seata 如何实现逆向回滚
7，如果协调者宕机了，参与事务是回滚还是提交
8，如果协调者宕机发起方没有通知协调者到底是提交还是回滚？

SpringCloud微服务技术栈.黑马跟学

今日目标

1.分布式事务问题

1.1.本地事务

本地事务，也就是传统的单机事务。在传统数据库事务中，必须要满足四个原则：

1.2.分布式事务

分布式事务，就是指不是在单个服务或单个数据库架构下，产生的事务，例如：

跨数据源的分布式事务
跨服务的分布式事务
综合情况

在数据库水平拆分、服务垂直拆分之后，一个业务操作通常要跨多个数据库、服务才能完成。例如电商行业中比较常见的下单付款案例，包括下面几个行为：

创建新订单
扣减商品库存
从用户账户余额扣除金额

完成上面的操作需要访问三个不同的微服务和三个不同的数据库。

订单的创建、库存的扣减、账户扣款在每一个服务和数据库内是一个本地事务，可以保证ACID原则。

但是当我们把三件事情看做一个"业务"，要满足保证“业务”的原子性，要么所有操作全部成功，要么全部失败，不允许出现部分成功部分失败的现象，这就是分布式系统下的事务了。

此时ACID难以满足，这是分布式事务要解决的问题

1.3.演示分布式事务问题

我们通过一个案例来演示分布式事务的问题：
1）创建数据库，名为seata_demo，然后导入课前资料提供的SQL文件：

2）导入课前资料提供的微服务：

微服务结构如下：

其中：
seata-demo：父工程，负责管理项目依赖

account-service：账户服务，负责管理用户的资金账户。提供扣减余额的接口
storage-service：库存服务，负责管理商品库存。提供扣减库存的接口
order-service：订单服务，负责管理订单。创建订单时，需要调用account-service和storage-service

3）启动nacos、所有微服务
4）测试下单功能，发出Post请求：
先尝试扣减成功的情况
postMan输入

http://localhost:8082/order?userId=user202103032042012&commodityCode=100202003032041&count=2&money=200

点击send后发现返回200

查看数据库，订单表，产生数量是2的订单

库存表库存从10变为了8

个人余额从1000变成了800

再尝试扣减失败的情况
请求如下：

在postman中访问

http://localhost:8082/order?userId=user202103032042012&commodityCode=100202003032041&count=10&money=200

如图：

点击send之后，发现报了500

看下数据库，个人账户从800竟然变成了600，这明显是有问题的

测试发现，当库存不足时，如果余额已经扣减，并不会回滚，出现了分布式事务问题。

分布式服务的事务问题
在分布式系统下，一个业务跨越多个服务或数据源,每个服务都是一个分支事务, 要保证所有分支事务最终状态一致,这样的事务就是分布式事务。

2.理论基础

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

2.1.CAP定理

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

Consistency（一致性）
Availability（可用性）
Partition tolerance （分区容错性）

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

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

2.1.1.一致性

Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致。

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

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

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

2.1.2.可用性

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

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

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

解决方案：在node3节点没恢复网络之前，所有访问node3的请求全都阻塞住，等到网络恢复后，再进行数据同步和请求响应。
问题：在网络恢复前，无法保证可用性，响应都阻塞了。这说明了，想要保证一致性，却牺牲了可用性。

2.1.3.分区容错

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

Tolerance（容错）：在集群出现分区时，整个系统也要持续对外提供服务

2.1.4.矛盾

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

当节点接收到新的数据变更时，就会出现问题了：

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

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

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

总结：
简述CAP定理内容?
● 分布式系统节点通过网络连接，一定会出现分区问题§
● 当分区出现时，系统的一致性©和可用性(A)就无法同时满足

思考: elasticsearch集群是CP还是AP?
答：CP
ES集群出现分区时，故障节点会被剔除集群，数据分片会重新分配到其它节点，保证数据一致。因此是低可用性,高一致性，属于CP

2.2.BASE理论

BASE理论是对CAP的一种解决思路，包含三个思想：

Basically Available （基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
**Soft State（软状态）：**在一定时间内，允许出现中间状态，比如临时的不一致状态。
Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。

2.3.解决分布式事务的思路

分布式事务最大的问题是各个子事务的一致性问题，因此可以借鉴CAP定理和BASE理论，有两种解决思路：

AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。
CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。

但不管是哪一种模式，都需要在子系统事务之间互相通讯，协调事务状态，也就是需要一个事务协调者(TC)：

这里的子系统事务，称为分支事务；有关联的各个分支事务在一起称为全局事务。

总结：
简述BASE理论三个思想:
● 基本可用
● 软状态
● 最终一致
解决分布式事务的思想和模型:

3.初识Seata

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

官网地址：http://seata.io/，其中的文档、播客中提供了大量的使用说明、源码分析。

3.1.Seata的架构

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

TC (Transaction Coordinator) - **事务协调者：**维护全局和分支事务的状态，协调全局事务提交或回滚。
TM (Transaction Manager) - **事务管理器：**定义全局事务的范围、开始全局事务、提交或回滚全局事务。
RM (Resource Manager) - **资源管理器：**管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

整体的架构如图：

Seata基于上述架构提供了四种不同的分布式事务解决方案：

XA模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入
TCC模式：最终一致的分阶段事务模式，有业务侵入
AT模式：最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式
SAGA模式：长事务模式，有业务侵入

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

3.2.部署TC服务

参考课前资料提供的文档《 seata的部署和集成.md 》：

seata的部署和集成

一、部署Seata的tc-server

1.下载

首先我们要下载seata-server包，地址在http 😕/seata.io/zh-cn/blog/download .html

当然，课前资料也准备好了：

2.解压

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

3.修改配置

修改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 = "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"

• group = “DEFAULT_GROUP” ：与Nacos中分组一致

4.在nacos添加配置

特别注意，为了让tc服务的集群可以共享配置，我们选择了nacos作为统一配置中心。因此服务端配置文件seataServer.properties文件需要在nacos中配好。
格式如下：

DataID: seataServer.properties
Group:DEFAULT_GROUP
配置格式:Properties

配置内容如下：

# 数据存储方式，db代表数据库
store.mode=db
store.db.datasource=druid
store.db.dbType=mysql
store.db.driverClassName=com.mysql.jdbc.Driver
store.db.url=jdbc:mysql://127.0.0.1:3306/seata_tc?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

其中的数据库地址、用户名、密码都需要修改成你自己的数据库信息。

5.创建数据库表

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

新建一个名为seata_tc的数据库，运行课前资料提供的sql文件：
这里数据库名称和上面nacos中配置文件的数据库名称一致即可

这些表主要记录全局事务、分支事务、全局锁信息：


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;

6.启动TC服务

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

默认端口是8091

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

打开浏览器，访问nacos地址：http://localhost:8848，然后进入服务列表页面，可以看到seata-tc-server的信息：

点击进去看到详情

二、微服务集成seata

1.引入依赖

首先，我们需要在微服务中引入seata依赖：
参与微服务的所有模块pom.xml都要加上

    <!-- 版本信息 父工程指定即可 -->
    <properties>
        <seata.version>1.4.2</seata.version>
    </properties>
    
<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.修改配置文件

需要修改application.yml文件，添加一些配置：
把所有服务模块的application.yml文件都修改一下

seata:
  registry: # TC服务注册中心的配置，微服务根据这些信息去注册中心获取tc服务地址
    # 参考tc服务自己的registry.conf中的配置
    type: nacos
    nacos: # tc
      server-addr: 127.0.0.1:8848
      namespace: ""
      group: DEFAULT_GROUP
      application: seata-tc-server # tc服务在nacos中的服务名称
      username: nacos
      password: nacos
  tx-service-group: seata-demo # 事务组，根据这个获取tc服务的cluster名称
  service:
    vgroup-mapping: # 事务组与TC服务cluster的映射关系
      seata-demo: SH

配置好之后，重启服务即可，看到seata中显示RM register success即成功了

三、TC服务的高可用和异地容灾

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文件：

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来决定了。

3.3.微服务集成Seata

我们以order-service为例来演示。

3.3.1.引入依赖

首先，在order-service中引入依赖：

<!--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>
<dependency>
    <groupId>io.seata</groupId>
    <artifactId>seata-spring-boot-starter</artifactId>
    <!--seata starter 采用1.4.2版本-->
    <version>$seata.version</version>
</dependency>

3.3.2.配置TC地址

在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: SH

微服务如何根据这些配置寻找TC的地址呢？

我们知道注册到Nacos中的微服务，确定一个具体实例需要四个信息：

namespace：命名空间
group：分组
application：服务名
cluster：集群名

以上四个信息，在刚才的yaml文件中都能找到：

namespace为空，就是默认的public

结合起来，TC服务的信息就是：public@DEFAULT_GROUP@seata-tc-server@SH，这样就能确定TC服务集群了。然后就可以去Nacos拉取对应的实例信息了。

3.3.3.其它服务

其它两个微服务也都参考order-service的步骤来做，完全一样。

4.动手实践

下面我们就一起学习下Seata中的四种不同的事务模式。

4.1.XA模式

XA 规范是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准，XA 规范描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对 XA 规范提供了支持。

4.1.1.两阶段提交

XA是规范，目前主流数据库都实现了这种规范，实现的原理都是基于两阶段提交。

正常情况：

异常情况：

一阶段：

事务协调者通知每个事物参与者执行本地事务
本地事务执行完成后报告事务执行状态给事务协调者，此时事务不提交，继续持有数据库锁

二阶段：

事务协调者基于一阶段的报告来判断下一步操作
- 如果一阶段都成功，则通知所有事务参与者，提交事务
- 如果一阶段任意一个参与者失败，则通知所有事务参与者回滚事务。

4.1.2.Seata的XA模型

Seata对原始的XA模式做了简单的封装和改造，以适应自己的事务模型，基本架构如图：

RM一阶段的工作：

① 注册分支事务到TC

② 执行分支业务sql但不提交

③ 报告执行状态到TC

TC二阶段的工作：

TC检测各分支事务执行状态

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

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

RM二阶段的工作：

接收TC指令，提交或回滚事务

4.1.3.优缺点

XA模式的优点是什么？

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

XA模式的缺点是什么？

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

4.1.4.实现XA模式

Seata的starter已经完成了XA模式的自动装配，实现非常简单，步骤如下：

1）修改application.yml文件（每个参与事务的微服务），开启XA模式：

seata:
  data-source-proxy-mode: XA

2）给发起全局事务的入口方法添加@GlobalTransactional注解:

本例中是OrderServiceImpl中的create方法.

3）重启所有服务并测试
重启order-service，再次测试，发现无论怎样，三个微服务都能成功回滚。
先看下数据库目前的状态
个人账户余额600

库存数量8

用postman发送订单，成功的

点击send

查看数据库，个人账户余额400

库存数量6

没问题，然后我们尝试一下失败的情况

点击send

查看数据库，个人账户余额不变

库存也不变

事务的一致性得到了保障

4.2.AT模式

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

4.2.1.Seata的AT模型

基本流程图：

阶段一RM的工作：

注册分支事务
记录undo-log（数据快照）
执行业务sql并提交
报告事务状态

阶段二提交时RM的工作：

删除undo-log即可

阶段二回滚时RM的工作：

根据undo-log恢复数据到更新前
再删除undo-log

4.2.2.流程梳理

我们用一个真实的业务来梳理下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

流程图：

4.2.3.AT与XA的区别

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

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

4.2.4.脏写问题

在多线程并发访问AT模式的分布式事务时，有可能出现脏写问题，如图：

解决思路就是引入了全局锁的概念。在释放DB锁之前，先拿到全局锁。避免同一时刻有另外一个事务来操作当前数据。

4.2.5.优缺点

AT模式的优点：

一阶段完成直接提交事务，释放数据库资源，性能比较好
利用全局锁实现读写隔离
没有代码侵入，框架自动完成回滚和提交

AT模式的缺点：

两阶段之间属于软状态，属于最终一致
框架的快照功能会影响性能，但比XA模式要好很多

4.2.6.实现AT模式

AT模式中的快照生成、回滚等动作都是由框架自动完成，没有任何代码侵入，因此实现非常简单。
只不过，AT模式需要一个表来记录全局锁、另一张表来记录数据快照undo_log。

1）导入数据库表，记录全局锁

导入课前资料提供的Sql文件：seata-at.sql，其中lock_table导入到TC服务关联的数据库，undo_log表导入到微服务关联的数据库：
lock_table表：放入seata_tc数据库
undo_log表：放入seata_demo数据库

添加后如下：

2）修改application.yml文件，将事务模式修改为AT模式即可：

seata:
  data-source-proxy-mode: AT # 默认就是AT

3）重启所有微服务并测试
我们用postman直接测试失败的情况，初始情况余额是400，库存是6

点击send,发现报错500

查看余额，还是400没问题

查看库存还是6没问题

4.3.TCC模式

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

Try：资源的检测和预留；
Confirm：完成资源操作业务；要求 Try 成功 Confirm 一定要能成功。
Cancel：预留资源释放，可以理解为try的反向操作。

4.3.1.流程分析

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

阶段一（ Try ）：检查余额是否充足，如果充足则冻结金额增加30元，可用余额扣除30

初识余额：

余额充足，可以冻结：

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

阶段二（Confirm)：假如要提交（Confirm），则冻结金额扣减30

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

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

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

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

4.3.2.Seata的TCC模型

Seata中的TCC模型依然延续之前的事务架构，如图：

4.3.3.优缺点

TCC模式的每个阶段是做什么的？

Try：资源检查和预留
Confirm：业务执行和提交
Cancel：预留资源的释放

TCC的优点是什么？

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

TCC的缺点是什么？

有代码侵入，需要人为编写try、Confirm和Cancel接口，太麻烦
软状态，事务是最终一致
需要考虑Confirm和Cancel的失败情况，做好幂等处理

4.3.4.事务悬挂和空回滚

1）空回滚

当某分支事务的try阶段阻塞时，可能导致全局事务超时而触发二阶段的cancel操作。在未执行try操作时先执行了cancel操作，这时cancel不能做回滚，就是空回滚。

如图：

执行cancel操作时，应当判断try是否已经执行，如果尚未执行，则应该空回滚。

2）业务悬挂

对于已经空回滚的业务，之前被阻塞的try操作恢复，继续执行try，就永远不可能confirm或cancel ，事务一直处于中间状态，这就是业务悬挂。

执行try操作时，应当判断cancel是否已经执行过了，如果已经执行，应当阻止空回滚后的try操作，避免悬挂

4.3.5.实现TCC模式

解决空回滚和业务悬挂问题，必须要记录当前事务状态，是在try、还是cancel？

1）思路分析

这里我们定义一张分支事务表：
在seata-demo中执行

CREATE TABLE `account_freeze_tbl` (
  `xid` varchar(128) NOT NULL,
  `user_id90 SpringCloud 解决分布式事务--lcn解决分布式事务
 SpringCloud Alibaba 使用Seata解决分布式事物
 SpringCloud----分布式事务
 springcloud分布式事务终极探讨
 分布式事务那些事
 SpringCloud Alibaba Seata---处理分布式事务