深度解读分布式事务Seata入门到实践 -尚马教育

目录

  • 一、事务的回顾
    • 1、什么是事务
    • 2、事务的特性
    • 3、事务的隔离级别
    • 4、事务的分类
  • 二、分布式事务
    • 1、什么是分布式事务
    • 2、分布式事务产生的背景
    • 3、分布式事务产生的场景
    • 4、分布式事务理论
      • ==4.1 CAP理论==
      • 4.2 Base理论
    • 5、分布式事务的解决方案
  • 三、强一致性介绍
    • 3.1 基本理解
    • 3.2 DTP模型
    • 3.3 落地协议XA
    • 3.4 ⼆阶段提交模型
    • 3.5 ⼆阶段提交的问题
    • 3.6 navicat操作xa
  • 四、XA强一致性实战
    • 4.1 XA强⼀致性JDBC实战
    • 4.2 XA强⼀致性Mybatis操作实战
  • 七、API的⽅式解决Mybaits事务

一、事务的回顾

1、什么是事务

事务表示逻辑上的⼀组操作,⼀个不可分割的执⾏单元,这个单元中的所有操作要嘛全部执⾏成功,要嘛全部执⾏失败

2、事务的特性

深度解读分布式事务Seata入门到实践 -尚马教育_第1张图片

3、事务的隔离级别

4、事务的分类

深度解读分布式事务Seata入门到实践 -尚马教育_第2张图片

  • 扁平事务
    深度解读分布式事务Seata入门到实践 -尚马教育_第3张图片

  • 扁平事务(保存点)
    深度解读分布式事务Seata入门到实践 -尚马教育_第4张图片

  • 链式事务

  • 嵌套事务

  • 分布式事务

二、分布式事务

1、什么是分布式事务

一组操作会产⽣多个数据库session会话 此时就会出现分布式事务

2、分布式事务产生的背景

1)数据库的数据量大,最终拆库拆表,把一个数据库中的数据,放到多台数据库中
⽐如: shardingSphere 再⽐如 springBoot项⽬配置多数据源等等

2)项目架构的转变
项⽬从单体架构->垂直架构->分布式架构->soa架构->微服务架构

3、分布式事务产生的场景

1) 跨数据库
⽐较典型的就是单体项⽬数据层进⾏拆库拆表,或者单体项⽬多数据源的情况

2)跨进程
⽐如多个服务访问的是同⼀个数据库 这种情况下 很少⻅ 但是照样会出现分布式事务

3)跨jvm进程,跨数据库
比较典型的就是微服务项目,一个事务的执行需要牵扯到多个服务,每个服务又有自己的数据库,跨项⽬ ⼜ 跨数据库

【总结】

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

4、分布式事务理论

4.1 CAP理论

CAP理论指:分布式事务中,不能同时满足一致性,可用性,分区容忍性

  • C:表示⼀致性(Consistency)
  • A : 表示可⽤性(Availability)
  • P:表示分区容忍性(Partition Tolerance)

一致性:一致性表示用户对数据的修改操作,在所有的副本中,要么全部执行成功,要么全部执行失败。(强调的是数据必须一致,允许锁等待和超时)

可⽤性:表示数据库节点可⽤即可,即客户端访问数据的时候 不存在超时 错误响应 能够快速响应结果。此时节点中的数据可以⼀致 也可以不⼀致,可⽤性的关注点就是系统可⽤,访问时可以快速给响应即可。

⽐如 mysql的读写分离 当对主机添加数据时,从机会复制这条数据 当客户端读取从机时 不能超时报错必须得有响应。此时允许读取的数据不是最新的。从机还不能被锁定

分区容忍性:表示把存储系统部署在多个节点中,并且这些节点在不同的⽹络节点中,这就形成了⽹络分区,由于⽹络问题节点之间的通讯可能失败,分区容忍性表示 就算节点通讯失败 照样能对外提供服务

【总结】一致性和可用性是矛盾的
深度解读分布式事务Seata入门到实践 -尚马教育_第5张图片

4.2 Base理论

对 cap中的ap模式做客一个拓展,它牺牲了一致性,换来可用性

在base理论中 强调了三点:

1)基本可用

是指在分布式系统中 如果出现故障,允许系统损失部分功能,但是要保证系统基本可⽤ ⽽不是整个系统死掉(⽐如我们购买⽕⻋票时 下订单经常出错 当下订单功能出错时 我们还可⽤正常查询⻋票 ⽽不是整个12306瘫痪)

2)软状态
软状态指允许系统存在中间状态,中间状态不会影响系统的整体可⽤性,允许系统各个节点中数据同步延迟。

3)最终一致性
最终⼀致性表示 允许分布式系统中各个节点的数据存在不⼀致的情况 但是经过⼀段时间,各
个节点上的数据 最终还是⼀致的。

5、分布式事务的解决方案

强⼀致性 cp:XA协议(数据库级别的规范,需要数据库的支持)

弱⼀致性 ap

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

三、强一致性介绍

3.1 基本理解

相关特点
强⼀致性解决⽅案要求在任何时间点 任何时刻查询 参与全局事务的各个节点的数据都必须是⼀致的

解决思想

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

3.2 DTP模型

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

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

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

3.3 落地协议XA

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

3.4 ⼆阶段提交模型

是基于 DTP模型的
表示在规范的情况下,事务的完成分为2个阶段
1:prepare阶段
2:Commit rollback阶段

第⼀个阶段: 资源服务器执⾏xa prepare。
事务管理器通知资源管理器,让资源管理器为提交事务做准备,资源管理器收到消息后,执⾏sql 执⾏本地事务,执⾏完毕之后不会提交事务,向事务管理器说我执⾏sql没有出现问题 已经准备好了提交

第⼆个阶段:
如果各个资源管理器都执⾏成功,事务管理器则向各个资源管理器发送提交事务的请求,各个资源管理器收到请求之后 执⾏本地事务提交然后释放资源。
如果有资源管理器返回的是失败 事务管理器则向各个资源管理器发送回滚事务的请求,各个资源管理器收到请求之后 执⾏事务回滚 然后释放资源

成功模型图
深度解读分布式事务Seata入门到实践 -尚马教育_第6张图片

失败模型图
深度解读分布式事务Seata入门到实践 -尚马教育_第7张图片

3.5 ⼆阶段提交的问题

深度解读分布式事务Seata入门到实践 -尚马教育_第8张图片

3.6 navicat操作xa

四、XA强一致性实战

4.1 XA强⼀致性JDBC实战

4.2 XA强⼀致性Mybatis操作实战

七、API的⽅式解决Mybaits事务

你可能感兴趣的:(#,Seata,seata)