分布式事务Seata讲解记录

最新推荐文章于 2024-09-13 17:34:44 发布
最新推荐文章于 2024-09-13 17:34:44 发布
阅读量1.5k 收藏 2
点赞数
分类专栏： java seate 分布式事务 文章标签： spring seata 分布式事务
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_36961226/article/details/120696083
版权
java 同时被 3 个专栏收录
99 篇文章 2 订阅
订阅专栏
seate
3 篇文章 0 订阅
订阅专栏
分布式事务
3 篇文章 0 订阅
订阅专栏

本地事务执行流程流程

数据库undo.log的工作原理
在操作数据之前会先将数据备份到Undo.log中，然后进行修改数据，如果出现错误或者用户执行
ROLLBACK语句，系统可以利用Undo.log中的备份将数据恢复到事务开始之前的状态。

执行流程
假设有A、B两个数据，值为 1,2
1、事务开始
2、记录A=1到undo.log
3、修改A=3
4、记录B=2到undo.log
5、修改B=4
6、将undo.log写入磁盘
7、将数据写入到磁盘
8、事务提交

在事务提交之前事务备份和修改先在内存中执行，效率高，然后写入磁盘持久化

事务如何保证持久化呢
先写入磁盘持久化，再提交事务，也就是说提交事务之前已一定会写入磁盘

数据库Redo.log（和undo.log相反）undo.log是记录旧数据，redo.log是记录新数据
假设有A、B两个数据，值为 1,2
1、事务开始
2、记录A=1到undo.log buffer(内存缓冲区)
3、修改A=3
4、记录A=3到redo.log buffer
5、记录B=2到undo.log buffer
6、修改B=4
7、记录B=4到redo.log buffer
8、将undo.log写入磁盘
9、将redo.log写入磁盘
10、事务提交

undo.log是写入到redo.log中的 所以说先记录旧数据在记录新数据
undo.log主要是记录事务前的数据（不可替代）

磁盘写入数据方式，简图

磁盘写入方式分为： 随机写和顺序写
redo.log的顺序写（效率高）
数据库数据写入磁盘是随机写（需要先寻址（耗费大量时间））

什么是CAP

  • Consistency（一致性）

  • Availability（可用性）

  • Partition tolerance （分区容错性）

1、先看 Partition tolerance，中文叫做"分区容错"。

大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。分区容错的意思是，区间通信可能失败。比如，一台服务器放在上海，另一台服务器放在北京，这就是两个区，它们之间可能因网络问题无法通信。

         上图中，G1 和 G2 是两台跨区的服务器。G1 向 G2 发送一条消息，G2 可能无法收到。系统设计的时候，必须考虑到这种情况。
       一般来说，分布式系统，分区容错无法避免，因此可以认为 CAP 的 P 总是成立。根据CAP 定理，剩下的 C 和 A 无法同时做到。

2.Consistency

        写操作之后的读操作，必须返回该值。举例来说，某条记录是 v0，用户向 G1 发起一个写操作，将其改为 v1。

 接下来，用户的读操作就会得到 v1。这就叫一致性。

 问题是，用户有可能向 G2 发起读操作，由于 G2 的值没有发生变化，因此返回的是 v0。G1 和 G2 读操作的结果不一致，这就不满足一致性了。

 为了让 G2 也能变为 v1，就要在 G1 写操作的时候，让 G1 向 G2 发送一条消息，要求 G2 也改成 v1。

 这样的话，用户向 G2 发起读操作，也能得到 v1。

 3.Availability

        Availability 中文叫做"可用性"，意思是只要收到用户的请求，服务器就必须给出回应（对和错不论）。
        用户可以选择向 G1 或 G2 发起读操作。不管是哪台服务器，只要收到请求，就必须告诉用户，到底是 v0 还是 v1，否则就不满足可用性。

4.Consistency 和 Availability 的矛盾

        一致性和可用性，为什么不可能同时成立？
        答案很简单，因为可能通信失败（即出现分区容错）。
        如果保证 G2 的一致性，那么 G1 必须在写操作时，锁定 G2 的读操作和写操作。只有数据同步后，才能重新开放读写。锁定期间，G2 不能读写，没有可用性不。
        如果保证 G2 的可用性，那么势必不能锁定 G2，所以一致性不成立。
        综上所述，G2 无法同时做到一致性和可用性。系统设计时只能选择一个目标。如果追求一致性，那么无法保证所有节点的可用性；如果追求所有节点的可用性，那就没法做到一致性。

Base理论

BASE是三个单词的缩写：

  • Basically Available（基本可用）

  • Soft state（软状态）

  • Eventually consistent（最终一致性）（G1-G2数据同步需要隔一段时间（比如：1毫秒））

一致性不是立刻一 致性，是隔一段时间后最终一直

基本可用是基本可以使用（不是完全不可用）隔一段时间后就可以使用了。

由上面的两种思想，延伸出了很多的分布式事务解决方案：

  • XA

  • TCC

  • 可靠消息最终一致

  • AT

TCC

它本质是一种补偿的思路。事务运行过程包括三个方法，

  • Try：资源的检测和预留；

  • Confirm：执行的业务操作提交；要求 Try 成功 Confirm 一定要能成功；

  • Cancel：预留资源释放。

执行分两个阶段：

  • 准备阶段（try）：资源的检测和预留；

  • 执行阶段（confirm/cancel）：根据上一步结果，判断下面的执行方法。如果上一步中所有事务参与者都成功，则这里执行confirm。反之，执行cancel

  • 优势

    TCC执行的每一个阶段都会提交本地事务并释放锁，并不需要等待其它事务的执行结果。而如果其它事务执行失败，最后不是回滚，而是执行补偿操作。这样就避免了资源的长期锁定和阻塞等待，执行效率比较高，属于性能比较好的分布式事务方式。

  • 缺点

    • 代码侵入：需要人为编写代码实现try、confirm、cancel，代码侵入较多

    • 开发成本高：一个业务需要拆分成3个步骤，分别编写业务实现，业务编写比较复杂

    • 安全性考虑：cancel动作如果执行失败，资源就无法释放，需要引入重试机制，而重试可能导致重复执行，还要考虑重试时的幂等问题

AT模式

        2019年 1 月份，Seata 开源了 AT 模式。AT 模式是一种无侵入的分布式事务解决方案。可以看做是对TCC或者二阶段提交模型的一种优化，解决了TCC模式中的代码侵入、编码复杂等问题。

在 AT 模式下，用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作。

可以参考Seata的官方文档。

2.7.1.基本原理

先来看一张流程图：

有没有感觉跟TCC的执行很像，都是分两个阶段：

  • 一阶段：执行本地事务，并返回执行结果

  • 二阶段：根据一阶段的结果，判断二阶段做法：提交或回滚

但AT模式底层做的事情可完全不同，而且第二阶段根本不需要我们编写，全部有Seata自己实现了。也就是说：我们写的代码与本地事务时代码一样，无需手动处理分布式事务。

那么，AT模式如何实现无代码侵入，如何帮我们自动实现二阶段代码的呢？

阶段一流程

 阶段二执行流程

提交操作：

        删除undo.log和redo.log等日志

回滚操作：

        查询undo.log，通过undo.log进行回滚

        回滚前 那redo.log 和数据库数据进行对比，看数据是否一致，如果一致直接回滚，不一致说明有其他人对数据进行了修改，此时需要人工干预，出现了脏数据。

这里的before image和after image类似于数据库的undo和redo日志，但其实是用数据库模拟的。

一阶段

        在一阶段，Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数据，在业务数据被更新前，将其保存成“before image”，然后执行“业务 SQL”更新业务数据，在业务数据更新之后，再将其保存成“after image”，最后获取全局行锁，提交事务。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。

二阶段提交

二阶段如果是提交的话，因为“业务 SQL”在一阶段已经提交至数据库， 所以 Seata 框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。

二阶段回滚：

二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。回滚方式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 “after image”，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。

不过因为有全局锁机制，所以可以降低出现脏写的概率。

AT 模式的一阶段、二阶段提交和回滚均由 Seata 框架自动生成，用户只需编写“业务 SQL”，便能轻松接入分布式事务，AT 模式是一种对业务无任何侵入的分布式事务解决方案。

2.7.2.详细架构和流程

Seata中的几个基本概念：

  • TC（Transaction Coordinator） - 事务协调者

    维护全局和分支事务的状态，驱动全局事务提交或回滚（TM之间的协调者）。

  • TM（Transaction Manager） - 事务管理器

    定义全局事务的范围：开始全局事务、提交或回滚全局事务。

  • RM（Resource Manager） - 资源管理器

    管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

我们看下面的一个架构图

  • TM：业务模块中全局事务的开启者

    • 向TC开启一个全局事务

    • 调用其它微服务

  • RM：业务模块执行者中，包含RM部分，负责向TC汇报事务执行状态

    • 执行本地事务

    • 向TC注册分支事务，并提交本地事务执行结果

  • TM：结束对微服务的调用，通知TC，全局事务执行完毕，事务一阶段结束

  • TC：汇总各个分支事务执行结果，决定分布式事务是提交还是回滚；

  • TC 通知所有 RM 提交/回滚 资源，事务二阶段结束。

一阶段：

  • TM开启全局事务，并向TC声明全局事务，包括全局事务XID信息

  • TM所在服务调用其它微服务

  • 微服务，主要有RM来执行

    • 查询before_image

    • 执行本地事务

    • 查询after_image

    • 生成undo_log并写入数据库

    • 向TC注册分支事务，告知事务执行结果

    • 获取全局锁（阻止其它全局事务并发修改当前数据）

    • 释放本地锁（不影响其它业务对数据的操作）

  • 待所有业务执行完毕，事务发起者（TM）会尝试向TC提交全局事务

二阶段：

  • TC统计分支事务执行情况，根据结果判断下一步行为

    • 分支都成功：通知分支事务，提交事务

    • 有分支执行失败：通知执行成功的分支事务，回滚数据

  • 分支事务的RM

    • 提交事务：直接清空before_image和after_image信息，释放全局锁

    • 回滚事务：

      • 校验after_image，判断是否有脏写

      • 如果没有脏写，回滚数据到before_image，清除before_image和after_image

      • 如果有脏写，请求人工介入

my_styles
关注
专栏目录
分布式事务Seata源码解析十：AT模式回滚日志undo log详细构建过程
健身变秃，coding变强
10-24 4125
AT模式下undo log的构建 和 持久化是分两阶段进行的： * **一阶段：** * 在执行业务SQL的同时，会根据业务SQL构建出before image 和 after image镜像数据的查询SQL； * 基于查询SQL的结果，每一列的数据采用`Field`对象存储、每一行数据采用`Row`对象存储，Row和Field对象的关系为一对多； * 由于业务SQL可能设计到多行，所以最终数据镜像采用`TableRecords`对象存储，TableRecords和Row也是一对多
谈谈被传的神乎其神的redo log那些机制，这次一次性帮你掌握了！
weixin_53170315的博客
12-08 1518
前言 作为研发同学的你可能真的没必要了解摸清楚关于redo log的这些机制。专注于写SQL完全能hold住日常的工作。 但是呢，感觉最好还是要了解一下，因为一般面试官都知道redo log是咋回事，其次是大家茶前饭后唠嗑时也能多少能插几句嘴。 一、引出 redo log 的作用 MySQL undo log相关的知识点，看下面这张脑图： 磁盘上的数据文件叫表空间文件，表空间有挺多的，比如系统表空间、undo log 表空间、你也可以让create出来的每张table都有自己单独的表空间。总之MySQ
【理论指导实践】Seata-TCC模式
m0_57042151的博客
12-28 117
概括来看，该模式有以下几个特点:该模式对代码的嵌入性高，开发工作较多，要求每个业务需要写TCC三步骤的操作。无论有没有本地事务控制都可以使用该模式，与底层数据库事务实现不相关，这个事务模式是抽象的基于服务层的概念，无论DB层是否有JDBC支持，即使没有JDBC的支持如redis、mongo、es等，只要将对他们的操作包装成TCC的参与者，就可以接入到TCC的事务范围内。并发度高，无需长期资源锁定，但并发问题、数据的一致性问题，需由开发者自行根据业务场景控制，开发要求高、难度偏大。
Seata的日志系统如何支持事务的监控和故障排查？
最新发布
qq_33240556的博客
09-13 439
Seata的日志系统是其分布式事务管理的重要组成部分，通过详细的日志记录，可以有效地监控事务的执行情况，并在出现问题时快速定位和解决问题。合理配置日志级别和路径，可以帮助开发人员和运维人员更好地理解和维护分布式事务系统。
盘点Seata : undo-log 处理
weixin_57907028的博客
07-21 9182
一 .前言 前面说了 Seata Client 的请求流程 , 这一篇来看一下 Client 端对 undo-log 的操作. undo-log 是 AT 模式中的核心部分 , 他是在 RM 部分完成的 , 在每一个数据库单元处理时均会生成一条 undoLog 数据. 二 . undo-log 表 先来看一下 undo-log 的表结构 CREATE TABLE `undo_log` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `branch_id` big
Seata入门系列(6)- undo_log支持的多种序列化方式
记录知识、锤炼自我
01-25 3094
文章目录rollback_infoundo 配置项支持的序列化方式自定义序列化使用fastjson时的主要事项 rollback_info 在undo_log表中，rollback_info字段存储了事务失败时，需要回滚的相关信息，该字段为longblob类型（二进制数据）。 在Navicat 中，可以选中当前数据，然后通过查看选择文本方式展示。 通过Json 格式化工具，可以查看到详细信息。 undo 配置项 @Component @ConfigurationProperties( prefi
分布式事务(Seata) 四大模式详解
YYniannian的博客
07-08 2133
Seata分为三大模块，分别是 TM、RM 和 TC TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，驱动全局事务提交或回滚。 TM (Transaction Manager) - 事务管理器：定义全局事务的范围：开始全局事务、提交或回滚全局事务。 RM (Resource Manager) - 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。...
分布式事务(Seata)原理 详解篇，建议收藏
java_beautiful的博客
07-12 745
前言 在之前的系列中，我们讲解了关于Seata基本介绍和实际应用，今天带来的这篇，就给大家分析一下Seata的源码是如何一步一步实现的。读源码的时候我们需要俯瞰起全貌，不要去扣一个一个的细节，这样我们学习起来会快捷而且有效率，我们学习源码需要掌握的是整体思路和核心点。 首先Seata客户端启动一般分为以下几个流程：...
五分钟带你了解Seata分布式事务，java开发实战经典答案
m0_64384350的博客
11-29 412
分支事务中数据的 本地锁 由本地事务管理，在分支事务 Phase1 结束时释放。· 同时，随着本地事务结束，连接 也得以释放。· 分支事务中数据的 全局锁 在事务协调器侧管理，在决议 Phase2 全局提交时，全局锁马上可以释放。只有在决议全 局回滚的情况下，全局锁 才被持有至分支的 Phase2 结束。 1.2.本地事务执行流程 在进行本地提交的前提是，seata 会解析 SQL，获取数据库表的元数据，根绝 SQL 类型，选择性地生成数据的前置镜像和后置镜像， 保存在 undolog 表...
从分布式事务解决到Seata使用，一梭子给你整明白了，web开发框架
jixuczy的博客
03-21 922
这个理论的核心思想便是：如果我们如法做到强一致性，那么每个应用都应该根据自身的业务特点，采用适当的方式来使系统达到最终一致性。出现场景====让我们回到分布式事务中来，什么时候会出现分布式事务呢？虽然时单体的架构服务，但由于在分库的情况下，依然会导致分布式事务的情况，因此单体服务不会出现分布式事务的这种说法，分布式架构下，两个服务之间相互调用，虽然使用的是同一个数据库，但是还是会出现分布式事务。谁让你使用的是分布式架构呢~
Java微服务分布式事务框架seata，字节跳动Python实习面试凉凉经
m0_60635321的博客
04-21 883
Python崛起并且风靡，因为优点多、应用领域广、被大牛们认可。学习 Python 门槛很低，但它的晋级路线很多，通过它你能进入机器学习、数据挖掘、大数据，CS等更加高级的领域。Python可以做网络应用，可以做科学计算，数据分析，可以做网络爬虫，可以做机器学习、自然语言处理、可以写游戏、可以做桌面应用…Python可以做的很多，你需要学好基础，再选择明确的方向。这里给大家分享一份全套的 Python 学习资料，给那些想学习 Python 的小伙伴们一点帮助！
Seata 2.x 系列【10】回滚日志表 undo_log
记录知识、锤炼自我
03-14 2565
在AT模式中，需要在参与全局事务的数据库中，添加一个undo_log表，类似于Mysql数据库中的undo log事务回滚日志表，在事务没提交之前，记录分支事务更新前的数据到日志表中，当全局事务需要回滚时，TC发出回滚命令，RM收到后使用undo log进行回退，并删除日志。
分布式事务以及seata介绍
memory
06-10 1729
一、单机事务 二、什么是分布式事务 三、分布式事务解决方案 四、分布式事务解决方案seata学习 五、seata源码学习
seata客户端【springboot/cloud实现seata】
JemeryShen的专栏
08-03 405
springboot/cloud实现seata
redo log和undo log写入的两阶段提交
互联网架构师笔记
05-09 279
两阶段提交就是执行完更新语句后，先将redo log状态设置为prepared，等更新内容写入binlog后，在将redo log状态设置为commited。
【MySQL】一文彻底搞懂 Redo-log 为什么要两阶段提交？
blblccc
03-29 5724
【MySQL】一文彻底搞懂 Redo-log 为什么要两阶段提交？
查看seata的undo_log日志（记录）
热门推荐
柚稚与酒
12-11 1万+
版本：seata：1.2 由此可知事务完成后undo_log日志被删除掉了 主要涉及的类： RmMessageListener：79行：日志打印打个断点。（模拟步骤忽略） 此时查看数据库： 个人记录
蚂蚁金服大规模分布式事务实践和开源详解 | GIAC 实录
07-03 277
本文整理自蚂蚁金服技术专家、分布式事务 Seata 发起者之一张森（花名：绍辉）在GIAC全球互联网架构大会的分享。详细讲解了在分布式架构演进中，蚂蚁金服面对的跨服务、跨数据库的业务数据一致性问题以及应对措施，并分享了分布式事务 Seata 的 AT、TCC、Saga 和 XA 四种模式。...
Apache Seata新特性支持 -- undo_log压缩
IT云清
07-06 731
对于Seata而言，是通过记录DML操作的前后的数据用于进行后续可能的回滚操作的，并且把这些数据保存到数据库的一个blob的字段里面。对于批量插入，更新，删除等操作，其影响的行数可能会比较多，拼接成一个大的字段插入到数据库，可能会带来以下问题：
分布式事务seata注解
07-27
Seata是一款开源的分布式事务解决方案，它提供了多种事务模式，包括AT、TCC、SAGA和XA。\[2\]在使用Seata时，可以使用注解来实现分布式事务。具体来说，可以使用@Transactional注解来标记需要参与分布式事务的方法或...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值