分布式事务

Lucky丶码农

已于 2023-05-17 15:35:04 修改

阅读量160

点赞数 1

文章标签：分布式数据库 java

于 2023-05-17 15:31:50 首次发布

本文链接：https://blog.csdn.net/m0_68226879/article/details/130726836

版权

分布式事务

分布式事务问题

本地事务

四个原则:

原子性
- 事务中的所有操作,要么全部成功,要么全部失败
一致性
- 要保证数据库内部完整性约束,声明性约束
隔离性
- 对同一资源操作的事务不能同时发生
持久性
- 对数据库做的一切修改将永久保存,不管是否出现故障

分布式事务

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

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

理论基础

CAP定理

分布式系统有三个指标:

Consistency(一致性)
Availability(可用性)
Partition tolerance(分区容错性)

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

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

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

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

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

矛盾:

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

(2).当节点接收到cinder数据变更时,就会出现问题:

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

如果此时要保证可用性,就不能等待网络恢复,那多个数据库之间就会出现数据不一致

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

BASE理论

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

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

解决分布式事务的思路

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

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

Seata

Seata的架构

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

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

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

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

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

部署Seata的tc-server

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

2.解压后,修改配置,修改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"
  }
}

微服务集成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>
<dependency>
    <groupId>io.seata</groupId>
    <artifactId>seata-spring-boot-starter</artifactId>
    <!--seata starter 采用1.4.2版本-->
    <version>${seata.version}</version>
</dependency>

配置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

XA模式

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

两阶段提交

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

一阶段：

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

二阶段：

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

Seata的XA模型

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

在这里插入图片描述

RM一阶段的工作：

① 注册分支事务到TC

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

③ 报告执行状态到TC

TC二阶段的工作：

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

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

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

RM二阶段的工作：

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

优缺点

XA模式的优点是什么？

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

XA模式的缺点是什么？

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

实现XA模式

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

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

seata:
  data-source-proxy-mode: XA

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

本例中是OrderServiceImpl中的create方法.

3）重启服务并测试

重启order-service，再次测试，发现无论怎样，三个微服务都能成功回滚。

AT模式

基本流程图：

在这里插入图片描述

阶段一RM的工作：

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

阶段二提交时RM的工作：

删除undo-log即可

阶段二回滚时RM的工作：

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

AT与XA的区别

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

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

脏写问题

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

在这里插入图片描述

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

在这里插入图片描述

但是，如果同时存在受seata管理的事务和不受seata管理的事务，则还是可能导致修改丢失，因此seata在记录redo log的时候要同时记录before image和after image。

优缺点

AT模式的优点：

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

AT模式的缺点：

两阶段之间属于软状态，属于最终一致
框架的快照功能会影响性能，但比XA模式要好很多
如果同时存在不受seata管理的本地事务，则可能会导致seata回滚失败

实现AT模式

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

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

演示AT回滚失败

如果after-image跟数据库的数据不一致会导致无法回滚

1）在OrderService中添加FailureHandler，在onRollbackRetrying中打断点

2）修改OrderService中feign的超时时间配置

feign:
  client:
    config:
      default:
        read-timeout: 30000
        connect-timeout: 30000

3）debug模式运行OrderService，并在扣减余额和扣减库存的feign调用方法上打断点

4）访问下单接口：http://localhost:8082/order，运行完扣用户余额以后，停在断点上，然后新发起一个不受seata事务管理的扣减余额的请求：http://localhost:8083/account/user202103032042012/100，然后继续执行扣减库存的请求，库存不够，导致回滚，可以看到回滚失败，进入FailureHandler，同时数据库中的lock_table和undo_log中的数据一直无法删除。