分布式事务

|下一秒待續

已于 2022-06-15 18:51:16 修改

阅读量138

点赞数

分类专栏：笔记文章标签：分布式数据库

于 2022-06-10 00:02:56 首次发布

本文链接：https://blog.csdn.net/weixin_51197191/article/details/125212355

版权

笔记专栏收录该内容

10 篇文章 0 订阅

订阅专栏

前言

本地事务

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

在这里插入图片描述

本地数据库的事务：
事务可以看做是一次大的活动，它由不同的小活动组成，这些活动要么全部成功，要么全部失败。

分布式事务

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

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

分布式系统中，多个服务操作多个数据库，不同服务参与同一个操作时，要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

一、CAP定理

       Consistency(一致性) ：对某个指定的客户端来说，读操作能返回最新的数据。如果读操作时，正在进行写操作，此时读操作会等待，当写操作完后，读操作再进行并返回最新的数据。
       Availability（可用性）: 客户端的请求，服务端并会有响应，此动作不会关系数据有没有同步，所有客户端获得的数据可能不是最新的数据。
       Partition tolerance（分区容错）: 在分布式系统中，由于网络等不稳定因素，导致系统服务间的数据没有同步，此时会出现数据上的错误，而这种数据上出错误是可以容忍存在。不稳定因素解决后，服务间的数据最终会同步。

分布式系统中CAP三者不能同时满足，分布式系统中P永远存在。

在这里插入图片描述

二、BASE理论

BASE理论（Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)）是对CAP理论的延伸,强调AP,满足BASE理论的事务，我们称之为“柔性事务”。

基本可用:分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。如，电商网站交易付款出现问题了，商品依然可以正常浏览。
软状态:允许系统中存在中间状态，这个状态不影响系统可用性，如订单的"支付中"状态、不同节点数据副本同步延迟等。
最终一致:最终一致是指经过一段时间后，所有节点数据都将会达到一致。如订单的"支付中"状态，早晚会变为“支付成功”或者"支付失败"，使订单状态与实际交易结果达成一致，但需要一定时间的延迟、等待。

三、分布式事务解决方案

1）2PC两阶段提交

两阶段提交协议(Two Phase Commitment Protocol)中，涉及到两种角色

一个事务协调者（coordinator）：负责协调多个参与者进行事务投票及提交(回滚)
多个事务参与者（participants）：即本地事务执行者

两阶段提交：(基于XA规范分布式事务解决)
prepare阶段：事务执行但不提交阶段
事务协调者通知每个事物参与者执行本地事务，本地事务执行完成后报告事务执行状态给事务协调者，此时事务不提交，继续持有数据库锁

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

2）TCC事务补偿

操作方法	含义
Try	预留业务资源/数据效验-尝试检查当前操作是否可执行
Confirm	确认执行业务操作，实际提交数据，不做任何业务检查。try成功，confirm必定成功
Cancel	执行业务出错时，需要回滚数据的状态下执行的业务逻辑

在这里插入图片描述

四、Seata

官网地址

1）Seata的架构

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

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

在这里插入图片描述

2）部署TC服务

1.下拉镜像和创建容器

#下拉镜像
docker pull seataio/seata-server:1.4.2

#创建容器
docker run \
 -e SEATA_IP=192.168.94.129 \
 -e SEATA_PORT=8091 \
 --name seata-server \
 -p 8091:8091 \
 -d \
 seataio/seata-server:1.4.2

2.创建seata的数据库和表
3.在nacos配置seata的tc配置信息

# 数据存储方式，db代表数据库
store.mode=db
store.db.datasource=druid
store.db.dbType=mysql
store.db.driverClassName=com.mysql.jdbc.Driver
store.db.url=jdbc:mysql://ip:3306/seata?useUnicode=true&rewriteBatchedStatements=true
store.db.user=root
store.db.password=itcast142
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容器中
#一定要修改registry.conf 配置信息
	nacos中的 id地址、组名、namespace

registry {
  # tc服务的注册中心类，这里选择nacos，也可以是eureka、zookeeper等
  type = "nacos"

  nacos {
    # seata tc 服务注册到 nacos的服务名称，可以自定义 spring.application.name
    application = "seata-tc-server"
    serverAddr = "139.224.74.35:8848"
    group = "DEFAULT_GROUP"
    namespace = ""
    cluster = "DEFAULT"
    username = "nacos"
    password = "nacos"
  }
}

config {
  # 读取tc服务端的配置文件的方式，这里是从nacos配置中心读取，这样如果tc是集群，可以共享配置
  type = "nacos"
  # 配置nacos地址等信息
  nacos {
    serverAddr = "139.224.74.35:8848"
    group = "DEFAULT_GROUP"
    namespace = ""
    username = "nacos"
    password = "nacos"
    dataId = "seataServer.properties"
  }
}

3）微服务集成Seata

引入依赖

<!--seata-->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
    <exclusions>
        <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>
    <version>${seata.version}</version>
</dependency>

配置TC地址
通过在yml文件中配置TC服务信息，通过nacos注册中心获取TC地址。

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

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

seata:
  registry:		 # TC服务注册中心的配置，微服务根据这些信息去注册中心获取tc服务地址
    type: nacos  # 注册中心类型 nacos
    nacos:
      server-addr:  	# nacos地址
      namespace:  		# namespace，默认为空
      group:  			# 分组，默认是DEFAULT_GROUP
      application: 	    # seata服务名称
      username: 
      password: 
  tx-service-group:	    # 事务组名称
  service:
    vgroup-mapping:     # 事务组与cluster的映射关系
      seata-demo:		#集群名

五、分布式方案模式

1）XA模式

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

在这里插入图片描述
RM一阶段的工作：

① 注册分支事务到TC

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

③ 报告执行状态到TC

TC二阶段的工作：

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

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

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

RM二阶段的工作：

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

`实现XA模式

Seata的starter已经完成了XA模式的自动装配。

修改yml文件

seata:
  data-source-proxy-mode: XA

给发起全局事务的方法添加@GlobalTransaction注解

2）AT模式

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

在这里插入图片描述

脏写问题

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

在这里插入图片描述

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

实现AT模式
AT模式中的快照生成、回滚等动作都是由框架自动完成，没有任何代码侵入，因此实现非常简单。

AT模式需要一个表来记录全局锁、另一张表来记录数据快照undo_log。
修改yml文件，将事务模式修改为AT

3）TCC模式

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

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

在这里插入图片描述

空回滚

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

在这里插入图片描述

业务悬挂

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

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

4）SAGA模式

Seata官网

在 Saga 模式下，分布式事务内有多个参与者，每一个参与者都是一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作。

分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会去退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。

在这里插入图片描述

六、小结：

在这里插入图片描述

XA模式优缺点：

优：

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

缺：

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

AT模式优缺点：

优：

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

缺：

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

TTC模式优缺点：

优：

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

缺：

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

SAGA模式优缺点：

优：

事务参与者可以基于事件驱动实现异步调用，吞吐高
一阶段直接提交事务，无锁，性能好
不用编写TCC中的三个阶段，实现简单

缺：

软状态持续时间不确定，时效性差
没有锁，没有事务隔离，会有脏写

|下一秒待續

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
分布式事务

本地事务，也就是传统的单机事务。在传统数据库事务中，必须要满足四个原则：本地数据库的事务：事务可以看做是一次大的活动，它由不同的小活动组成，这些活动要么全部成功，要么全部失败。分布式事务，就是指不是在单个服务或单个数据库架构下，产生的事务，例如：分布式系统中，多个服务操作多个数据库，不同服务参与同一个操作时，要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 Consistency(一致性) ：对某个指定的客户端来说，读操作能返回最新的数据。......
复制链接

扫一扫