1）本地事务

image.png

2）分布式事务

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

  • 在一个业务方法中跨数据源的分布式事务
  • 在一个业务方法中跨服务的分布式事务
  • 综合情况

  • image.png

    分布式事务问题

    当三个服务器一起执行的话,其中一个服务器的事情可能会执行失败,就会导致其他两个事务已经提交(数据已经修改),失败的事务就会回滚事务,产生数据(不一致)问题,例子:就会出现给了钱,不发货的情况

    04、分布式事务理论-CAP定理

    1）什么是CAP定理

    1998年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标。

  • Consistency（一致性）:用户访问分布式系统中的任意节点，得到的数据必须一致。

比如现在包含两个节点，其中的初始数据是一致的：两个修改成功叫一致性

  • Availability（可用性）:用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝。
  • 当有一个节点网络出现问题导致阻塞,这个叫不可用

image.png

  • Partition tolerance （分区容错性）因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。(自己理解)其中有一个区不能同步这个就是分区容错

  • image.png

    2）CAP定理矛盾点

    如果此时要保证c一致性，就必须等待网络恢复，完成数据同步后，整个集群才对外提供服务，服务处于阻塞状态，不可用。
    如果此时要保证a可用性，就不能等待网络恢复，那node01、node02与node03之间就会出现数据不一致。
    也就是说，在P(容错)一定会出现的情况下，A和C之间只能实现一个。

    05、分布式事务理论-BASE理论与解决分布式事务思路

    BASE理论是由eBay架构师提出的，是对CAP的一种解决思路，包含三个思想：
    1.Basically Available（基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用从而保持一致性。
    2.Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态,保证可用性。
    3.Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。
    分布式事务最大的问题是各个子事务的一致性问题,因此可以借鉴CAP定理和BASE理论，有两种解决思路：

  • AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。（强可用，弱一致）

  • CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。（强一致，弱可用）

image.png

06、整合Seata-Seata介绍

2）Seata架构

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

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

    Seata基于上述架构提供了四种不同的分布式事务解决方案：

    1.XA模式：

    (强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入（CP模式）)
    XA 规范 是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准，XA 规范 描述了全局的TM与局部的RM之间的接口，几乎所有主流的关系型数据库都对 XA 规范 提供了支持。

    2）两阶段提交

    Two Pharse Commit
    XA是规范，目前主流数据库都实现了这种规范，实现的原理都是基于两阶段提交。
    正常情况：
    image.png
    异常情况：
    image.pngXA(强一致,CP模式)流程RM(分支事务)第一阶段
    Tc服务器(事务协调者)请求给RM执行SQL语句但是还没提交(就会导致事务还没结束)目前是阻塞状态
    第二阶段
    RM就会上报状态信息(利用了日志,靠读写日志看这个SQL是否ok,然后就上报给TC事务协调者),上报完后就会写到分支事务表里,两个分支事务状态都ok的,TC服务器就会同时提交请求,然后分务表信息和全务信息里面的内容就会删除掉.
    失败的其中一个分支事务失败了就会把成功的事务回滚
    image.png

2.TCC模式：

最终一致的分阶段事务模式，有业务侵入（AP模式）
TCC模式与AT模式非常相似，每阶段都是独立事务，不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法：

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


第一阶段(Try)先检查余额是否充足,充足就就冻结金额30元(只是冻结更拍快照一个道理),在余额里扣除30,余额还剩70元,然后直接提交事务不需要等待
(此时，总金额 = 冻结金额 + 可用金额，数量依然是100不变。事务直接提交无需等待其它事务。)
第二阶段(Confirm)
假如提交了,就会把冻结的余额30块扣除掉,可用余额就剩下70块钱
image.png
在第一阶段出现问题就需要回滚,就会把冻结的三十块钱加回可用余额里面去
image.png
image.png
image.png

4）事务悬挂和空回滚

1）空回滚

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

3.AT模式：

最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式（AP模式重要）
image.png
第一阶段:先是调用SQL分支事务(undolog),然后就注册分务事务,执行SQL并提交同时会在(undolog表)里面记录更新前快照,上报事务成功状态
第二阶段
TC会发送提交请求,删除该RM对应分支事务表(undo.log)日志.
如果有一个RM在第一阶段失败了,回滚,吧第一阶段的更新前的快照覆盖掉修改后的数据
image.png
AT模式会出现脏写问题
一个事务读取另一个未提交的事务数据
解决脏写问题(写隔离)
先添加一个全局锁表lock
事务1 会获取全局锁(就会在全局锁表插入记录,只能插一条记录)
事务2没拿到锁就会在第一阶段执行SQL是没问题的,但是事务二不能在全局锁表里插入数据,就会反复去拿全局锁三十次间隔10毫秒,直到任务超时就会回滚,
4.SAGA模式：长事务模式，有业务侵入（AP模式）
非Seata管理事务,出现恶意篡改数据
就会拿后快照对比现在数据,不一样的话就会记录异常,发送警告,人工介入
image.png

4）AT与XA的区别

简述AT模式与XA模式最大的区别是什么？

  • XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源，AT模式的可用性比XA模式更好！
  • XA模式依赖数据库机制实现回滚；AT模式利用数据快照实现数据回滚。
  • XA模式强一致；AT模式弱一致（最终一致），AT模式一致性比XA更差！

13、Seata使用-四种模式对比

我们从以下几个方面来对比四种实现：

  • 一致性：能否保证事务的一致性？强一致还是最终一致？
  • 隔离性：事务之间的隔离性如何？
  • 代码侵入：是否需要对业务代码改造？
  • 性能：有无性能损耗？
  • 场景：常见的业务场景
  • image.png