分布式事务Seata

VIP文章邱秋Elena

已于 2023-10-17 10:37:44 修改

阅读量279

点赞数 1

文章标签： java

于 2023-10-16 17:08:39 首次发布

本文链接：https://blog.csdn.net/weixin_38380811/article/details/133804846

版权

文章目录

一、分布式事务概述
二、Seata分布式事务框架
三、Seata的XA模式
四、Seata的AT模式
五、Seata的TCC模式
六、Seata的高可用

一、分布式事务概述

（一）分布式事务产生的场景

场景⼀：跨数据库⽐较典型的就是单体项⽬数据层进⾏拆库拆表，或者单体项⽬多数据源的情况
场景⼆：跨进程⽐如多个服务访问的是同⼀个数据库这种情况下很少⻅但是照样会出现分布式事务
场景三跨jvm进程跨数据库⽐较典型的就是微服务项⽬⼀个事务的执⾏需要牵扯到多个服务每个服务都有⾃⼰的数据库跨项⽬⼜
跨数据库

总结
不管是跨进程还是跨数据库还是多服务访问单数据库都有⼀个本质的特点操作时可能存在多
个数据库session会话我们可以理解为如果⼀组操作会产⽣多个数据库session会话此时就会出
现分布式事务

（一）分布式事务理论

1、CAP理论

基本概述
CAP理论⼜叫布鲁尔定理由三部分组成，布鲁尔定理是指分布式事务中不可能同时满⾜⼀致性
可⽤性分区容忍性
C：表示⼀致性（Consistency）
A：表示可⽤性（Availability）
P：表示分区容忍性(Partition Tolerance)
⼀致性
⼀致性表示⽤户对数据的修改操作，在所有的副本中全部执⾏成功或者全部执⾏失败
⽐如： mysql的主从复制读写分离时，当对主库添加数据成功时从库必须也添加成功并且从从
库中读取数据时读取的应该是最新的数据不能出现主库添加数据后从从库中读取的不是最新的数据
⽐如在主从复制过程中读取从库此时数据还没有复制过来此时读取的可能就不是最新的数据此
时就不满⾜⼀致性了
所以想要满⾜⼀致性当主库添加数据时需要把数据同步到从库并且同步的时候需要锁定从库，
不能让从库参与读取，等到同步完成之后再取消锁定此时再读就是最新的数据了此时就满⾜了⼀致性。
可⽤性
可⽤性表示数据库节点可⽤即可，即客户端访问数据的时候不存在超时错误响应能够快速响应结果。此时节点中的数据可以⼀致也可以不⼀致，可⽤性的关注点就是系统可⽤访问时可以快速给响应即可。⽐如 mysql的读写分离当对主机添加数据时，从机会复制这条数据当客户端读取从机时不能超时报错必须得有响应。此时允许读取的数据不是最新的。从机还不能被锁定。
分区容忍性
分区容忍性表示把存储系统部署在多个节点中，并且这些节点在不同的⽹络节点中，这就形成了⽹络分区，由于⽹络问题节点之间的通讯可能失败，分区容忍性表示就算节点通讯失败照样能对外提供服务。⽐如：mysql的读写分离, 给主机添加⼀条数据时主机应该异步把数据复制给从机不能同步复制给从机，如果同步复制给从机导致主机线程阻塞影响⽤户⼆次插⼊（影响了主机对外提供添加数据服务），并且从机不能只有⼀个要有多个，如果只有⼀个从机从机挂了之后影响了读操作（影响了从机对外提供读取数据服务），如果有多个从机其中⼀个从机挂了其他的从机还会对外提供服务保证系统了正常运⾏

2、Base理论

Base理论是对CAP理论中的AP做了⼀个拓展说明，它牺牲了⼀致性换来了可⽤性。
在base理论中强调了三点

基本可⽤（basically Available）
是指在分布式系统中如果出现故障，允许系统损失部分功能，但是要保证系统基本可⽤⽽不是整个系统死掉，⽐如我们购买⽕⻋票时下订单经常出错当下订单功能出错时我们还可⽤正常查询⻋票⽽不是整个12306瘫痪
软状态 (soft state)
软状态指允许系统存在中间状态，中间状态不会影响系统的整体可⽤性，允许系统各个节点中数据同步延迟。⽐如当当⽹买书买完书之后退货此时有⼀个退款中的状态退款中的状态就属于中间状态.
最终⼀致性 (Eventually Consistent)
最终⼀致性表示允许分布式系统中各个节点的数据存在不⼀致的情况但是经过⼀段时间,各个节点上的数据最终还是⼀致的。

（一）分布式事务解决方案

1、强⼀致性

XA协议

2、弱⼀致性

TCC
可靠消息⼀致性
其他⽅式

（一）强⼀致性介绍

强⼀致性解决⽅案要求在任何时间点任何时刻查询参与全局事务的各个节点的数据都必须是⼀致的
强⼀致性解决⽅案在实际⽣产环境中银⾏系统⽤的⽐较多，因为银⾏对⾦额数据的⼀致性要求⽐较⾼⽽在其他对⼀致性要求不是特别⾼的系统中很少会被⽤到

解决思想：

DTP模型
2PC⼆阶段提交模型

1、DTP模型

DTP模型是X/Open组织定义的⼀套分布式事务标准，这个标准定义了解决分布式事务的规范和API接
⼝，由各地⼚商实现。

DTP模型提出三⼤组件：
1：应⽤程序（AP）：应⽤程序就是我们的项⽬控制着事务的开始和结束
2：资源管理器(RM)：资源管理器就是指事务的参与者在实际中就是我们的数据库
3：事务管理器™：负责管理协调事务负责分配事务的唯⼀标识

结论：
DTP模型，规范了分布式事务的模型设计(三⼤组件)

1、XA协议

XA则规范了TM与RM之间的通信接⼝，在TM与多个RM之间形成⼀个双向通信桥梁是数据库级别的规范。
规范如下：

xa_start 开启⼀个分⽀事务
xa_end 取消分⽀事务
xa_prepare 询问资源管理器是否做好了提交事务的准备
xa_commit 通知资源管理器提交事务
xa_rollback 通知事务管理器回滚事务
xa_recover 列出需要恢复的事务分⽀

mysql的innoDB引擎是⽀持XA的是基于XA的2阶段提交可以使⽤show engines \G查看

具体语法 xid表示事务唯⼀标识符
1：开启XA事务 xa start xid
2：结束XA事务 xa end xid
3：准备提交XA事务 xa prepare xid
4：提交xa事务 xa commit xid
5：回滚xa事务 xa rollback xid

1、⼆阶段提交模型

⼆阶段提交表示的是XA规范下的事务提交分为2个阶段

第⼀个阶段：资源服务器执⾏xa prepare。
1：事务管理器通知资源管理器，让资源管理器为提交事务做准备 2：资源管理器收到消息后执⾏sql 执⾏本地事务执⾏完毕之后不会提交事务
向事务管理器说我执⾏sql没有出现问题已经准备好了提交（注意当前资源管理器当前线程阻塞等待提交）
第⼆个阶段：
1：如果各个资源管理器都执⾏成功则向各个资源管理器发送提交事务的请求，
2：各个资源管理器收到请求之后执⾏本地事务提交然后释放资源
异常情况：
1：如果有资源管理器返回的是失败则向各个资源管理器发送回滚事务的请求，
2：各个资源管理器收到请求之后执⾏事务回滚然后释放资源

⼆阶段提交的问题:

1：同步阻塞问题。执⾏过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三⽅节点访问公共资源不得不处于阻塞状态。
2：单点故障。由于协调者的重要性，⼀旦协调者发⽣故障。参与者会⼀直阻塞下去。尤其在第⼆阶段
，协调者发⽣故障，那么所有的参与者还都处于锁定事务资源的状态中，⽽⽆法继续完成事务操作。
（如果是协调者挂掉，可以重新选举⼀个协调者，但是⽆法解决因为协调者宕机导致的参与者处于阻塞状态的问题）
3：数据不⼀致。在⼆阶段提交的阶段⼆中，当协调者向参与者发送commit请求之后，发⽣了局部⽹
络异常或者在发送commit请求过程中协调者发⽣了故障，这回导致只有⼀部分参与者接受到了commi
t请求。⽽在这部分参与者接到commit请求之后就会执⾏commit操作。但是其他部分未接到commit
请求的机器则⽆法执⾏事务提交。于是整个分布式系统便出现了数据不⼀致性的现象。
4：⼆阶段⽆法解决的问题：协调者再发出commit消息之后宕机，⽽唯⼀接收到这条消息的参与者同
时也宕机了。那么即使协调者通过选举协议产⽣了新的协调者，这条事务的状态也是不确定的，没⼈知道事务是否被已经提交。

二、Seata分布式事务框架

（一）Seata介绍

seata是由阿⾥巴巴开发的⼀款开源的分布式事务解决⽅案，社区极其活跃，国内使⽤的⼈很多，sea
ta致⼒于在微服务架构中提供⾼性能和简单易⽤的分布式事务服务，seata为开发者提供了AT TCC Saga和XA四种服务模式。

seata的组成⻆⾊：
在前⾯我们学习DTP模型时我们知道DTP模型分为了三个⻆⾊ AP TM 和RMseata在这个基础上⼜多加了⼀个⻆⾊ TC
1、TC (Transaction Coordinator) - 事务协调者
维护全局和分⽀事务的状态，驱动全局事务提交或回滚。
2、TM (Transaction Manager) - 事务管理器
定义全局事务的范围：开始全局事务、提交或回滚全局事务。
3、RM (Resource Manager) - 资源管理器
管理分⽀事务处理的资源，与TC交谈以注册分⽀事务和报告分⽀事务的状态,并驱动分⽀事务提交或回滚。

（一）普通单节点安装

（一）docker安装

三、Seata的XA模式

（一）多数据源

导入依赖

<!-- https://mvnrepository.com/artifact/io.seata/seata-spring-boot-starter
可以把druid数据源排除 因为seata中默认带druid -->
 <dependency>
	 <groupId>io.seata</groupId>
	 <artifactId>seata-spring-boot-starter</artifactId>
	 <version>1.5.2</version>
 </dependency>

yml配置

spring:
  mvc:
    pathmatch:
      matching-strategy: ant_path_matcher
  main:
    allow-circular-references: true
  datasource:
    db1:
      driver-class-name: com.mysql.cj.jdbc.Driver
      url: jdbc:mysql://127.0.0.1:3306/test1?serverTimezone=Asia/Shanghai
      username: root
      password: 123456
    db2:
      driver-class-name: com.mysql.cj.jdbc.Driver
      url: jdbc:mysql://127.0.0.1:3306/test2?serverTimezone=Asia/Shanghai
      username: root
      password: 123456
## seata的配置
seata:
	service:
		vgroup-mapping: