Seata 源码学习 (一) - 下载源码

Seata源码学习引入

学习了Seata的应用以后,我们从这开始要开始分析Seata的源码相关内容

源码下载

官方地址:https://seata.io/zh-cn/blog/download.html

Seata 源码学习 (一) - 下载源码_第1张图片

通过idea打开seata-1.4.2版本的源码

Seata 源码学习 (一) - 下载源码_第2张图片

回顾AT模式

其实在之前的应用课程中,我们已经用过AT模式,同时也写过一个小的Demo,那么这里其实我们主要要分析的是AT模式官方文档中的一些内容

官方文档:https://seata.io/zh-cn/docs/dev/mode/at-mode.html

写隔离

  • 一阶段本地事务提交前,需要确保先拿到 全局锁
  • 拿不到 全局锁 ,不能提交本地事务。
  • 全局锁 的尝试被限制在一定范围内,超出范围将放弃,并回滚本地事务,释放本地锁。

图解:

Seata 源码学习 (一) - 下载源码_第3张图片

如果 tx1 的二阶段全局回滚,则 tx1 需要重新获取该数据的本地锁,进行反向补偿的更新操作,实现分支的回滚。

此时,如果 tx2 仍在等待该数据的 全局锁,同时持有本地锁,则 tx1 的分支回滚会失败。分支的回滚会一直重试,直到 tx2 的 全局锁 等锁超时,放弃 全局锁 并回滚本地事务释放本地锁,tx1 的分支回滚最终成功。

因为整个过程 全局锁 在 tx1 结束前一直是被 tx1 持有的,所以不会发生 脏写 的问题。

读隔离

在数据库本地事务隔离级别 读已提交(Read Committed) 或以上的基础上,Seata(AT 模式)的默认全局隔离级别是 读未提交(Read Uncommitted)

如果应用在特定场景下,必需要求全局的 读已提交 ,目前 Seata 的方式是通过 SELECT FOR UPDATE 语句的代理。

图解:

Seata 源码学习 (一) - 下载源码_第4张图片

SELECT FOR UPDATE 语句的执行会申请 全局锁 ,如果 全局锁 被其他事务持有,则释放本地锁(回滚 SELECT FOR UPDATE 语句的本地执行)并重试。这个过程中,查询是被 block 住的,直到 全局锁 拿到,即读取的相关数据是 已提交 的,才返回。

出于总体性能上的考虑,Seata 目前的方案并没有对所有 SELECT 语句都进行代理,仅针对 FOR UPDATE 的 SELECT 语句。

AT二阶段

一阶段:

​ 1. 解析 SQL:得到 SQL 的类型(UPDATE),表(product),条件(where name = ‘TXC’)等相关的信息。

  1. 查询前镜像(改变之前的数据):根据解析得到的条件信息,生成查询语句,定位数据。
  2. 执行业务 SQL:更新这条数据。
  3. 查询后镜像(改变后的数据):根据前镜像的结果,通过 主键 定位数据。
  4. 插入回滚日志:把前后镜像数据以及业务 SQL 相关的信息组成一条回滚日志记录,插入到 UNDO_LOG 表中。
  5. 提交前,向 TC 注册分支:申请 全局锁
  6. 本地事务提交:业务数据的更新和前面步骤中生成的 UNDO LOG 一并提交。
  7. 将本地事务提交的结果上报给 TC。

二阶段-回滚:

  1. 收到 TC 的分支回滚请求,开启一个本地事务,执行如下操作。
  2. 通过 XID 和 Branch ID 查找到相应的 UNDO LOG 记录。
  3. 根据 UNDO LOG 中的前镜像和业务 SQL 的相关信息生成并执行回滚的语句:
  4. 提交本地事务。并把本地事务的执行结果(即分支事务回滚的结果)上报给 TC。

二阶段-提交:

  1. 收到 TC 的分支提交请求,把请求放入一个异步任务的队列中,马上返回提交成功的结果给 TC。
    的结果)上报给 TC。

二阶段-提交:

  1. 收到 TC 的分支提交请求,把请求放入一个异步任务的队列中,马上返回提交成功的结果给 TC。
  2. 异步任务阶段的分支提交请求将异步和批量地删除相应 UNDO LOG 记录。

你可能感兴趣的:(SpingCloud,spring,cloud,seata-server,分布式事务)