分布式事务,一致性理论, 两阶段提交（2PC）, 三阶段提交（3PC）,Seata分布式事务方案

上一篇降到了 分布式锁，先来和大家聊一聊分布式事务，
分布式锁的链接如下： https://blog.csdn.net/weixin_44797327/article/details/134611193?spm=1001.2014.3001.5502

分布式事务：

1、一致性理论

  分布式事务的目的是保障分库数据一致性，而跨库事务会遇到各种不可控制的问题，如个别节点永久性宕机，像单机事务一样的ACID是无法奢望的。另外，业界著名的CAP理论也告诉我们，对分布式系统，需要将数据的一致性、系统可用性、分区容忍性放在天平上一起考虑。

  两阶段提交协议（简称2PC） 是实现分布式事务较为经典的方案，但2PC 的可扩展性很差，在分布式架构下应用代价较大，eBay 架构师Dan Pritchett 提出了BASE 理论，用于解决大规模分布式系统下的数据一致性问题。BASE 理论 告诉我们：可以通过放弃系统在每个时刻的强一致性来换取系统的可扩展性。

• CAP理论
    在分布式系统中，**一致性（Consistency）、可用性（Availability）和分区容忍性（Partition Tolerance）**三个要素最多只能同时满足两个，不可兼得。其中 分区容忍性 又是不可或缺的。
  

  • 一致性：分布式环境下多个节点的数据是否强一致。
  • 可用性：分布式服务能一直保证可用状态。当用户发出一个请求后，服务能在有限时间内返回结果。
  • 分区容忍性：特指对网络分区的容忍性。即，系统中任意信息的丢失或失败不会影响系统的继续运作

• BASE 理论

  • 基本可用（Basically Available）：指分布式系统在出现故障时，允许损失部分的可用性来保证核心可用。
  • 软状态（Soft State）：指允许分布式系统存在中间状态，该中间状态不会影响到系统的整体可用性。
  • 最终一致性（Eventual Consistency）：指分布式系统中的所有副本数据经过一定时间后，最终能够达到一致的状态。

2、两阶段提交（2PC）

  二阶段提交协议（Two-phase Commit，即 2PC）是常用的分布式事务解决方案，即 将事务的提交过程分为准备阶段和提交阶段两个阶段来进行处理，通过引入协调者（Coordinator）来协调参与者的行为，并最终决定这些参与者是否要真正执行事务。

事务协调者（事务管理器）：事务的发起者
事务参与者（资源管理器）：事务的执行者

• 准备阶段（投票阶段）
     协调者询问参与者事务是否执行成功，参与者发回事务执行结果，但该阶段并未提交事务。

     1）协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待答复；
     2）各参与者执行事务操作，将 undo 和 redo 信息记入事务日志中（但不提交事务）；
     3）如果参与者执行成功，给协调者反馈同意，否则反馈终止。

• 提交阶段（执行阶段）
    如果事务在每个参与者上都执行成功，事务协调者发送通知让参与者提交事务；否则，协调者发送通知让参与者回滚事务。
    在准备阶段，参与者执行了事务，但是还未提交。只有在提交阶段接收到协调者发来的通知后，才进行提交或者回滚。

     1）事务协调者节点向所有参与者节点发出正式提交(commit)的请求；
     2）参与者节点正式完成操作，并释放在整个事务期间内占用的资源；
     3）参与者节点向协调者节点发送ACK完成消息；
     4）事务协调者节点收到所有参与者节点反馈的ACK完成消息后，完成事务。

• 2PC优缺

  • 优点
       尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。（其实也不能100%保证强一致，如宕机）

  • 缺点

    • 性能问题：执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。

    • 可靠性问题：参与者发生故障。协调者需要给每个参与者额外指定超时机制，超时后整个事务失败。协调者发生故障。参与者会一直阻塞下去。需要额外的备机进行容错。

    • 数据一致性问题：二阶段无法解决的问题如协调者在发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。

    • 实现复杂：牺牲了可用性，对性能影响较大，不适合高并发高性能场景。

3、三阶段提交（3PC）

    三阶段提交协议是二阶段提交协议的改进版本，其有两个改动点。

      1）在协调者和参与者中都引入超时机制；
      2）在第一阶段和第二阶段中插入一个准备阶段，保证了在最后提交阶段之前各参与节点的状态是一致的。

    即除了引入超时机制之外，3PC把2PC的准备阶段再次一分为二，这样三阶段提交就有CanCommit、PreCommit 和 DoCommit 三个阶段。

• 阶段1：CanCommit

  • 事务询问：协调者向参与者发送一个CanCommit事务请求，询问是否可以执行事务提交操作，开始等待参与者的响应。
  • 参与者向协调者反馈事务询问响应：参与者根据自身情况，反馈YES响应，进入预备状态，否则返回NO响应。

• 阶段2：PreCommit

  • 返回yes情况：

    • 1）协调者向所有参与者发送PreCommit请求，进入准备阶段；
    • 2）参与者收到PreCommit请求后，执行事务操作，将undo和redo信息记录到日志中。
    • 3）各参与者向协调者反馈事务执行响应：成功响应ACK，同时等待最终指令：提交还是终止。

  • 返回no情况（中断事务）：

    • 1）任一参与者向协调者反馈了 NO响应 或者等待 超时 之后，协调者无法接收到所有参与者反馈响应，那么中断事务。
    • 2）发送中断请求（abort请求）。
    • 3）参与者收到协调者abort请求或者等待协调者请求超时，参与者中断事务。

• 阶段3：DoCommit

  • 同步处理：
    • 发送提交请求：协调者正常工作状态，接收到来自所有参与者的ACK响应，那么它将从预提交状态转换为提交状态，向所有参与者发送DoCommit请求。
    • 事务提交：参与者收到DoCommit请求后，会正式执行事务提交操作，完成提交后，释放事务资源。
    • 反馈事务提交结果：参与者完成事务提交之后，向协调者发送ACK消息。
    • 完成事务：协调者收到所有参与者反馈的ACK消息后，完成事务。
  • 回滚处理：
    • 发送中断请求：协调者向所有参与者发送abort请求。
    • 事务回滚：参与者收到abort请求后，利用 阶段2中的undo日志来执行事务回滚操作，完成回滚，释放资源。
    • 反馈事务回滚结果：参与者完成了事务回滚后，向协调者发送ACK消息。
    • 协调者收到所有参与者反馈的ACK消息后，中断事务。

4、Seata分布式事务方案

    Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。

• Seata术语

  • TC（事务协调者）：维护全局和分支事务的状态，驱动全局事务提交或回滚。
  • TM（事务管理器）：定义全局事务的范围：开始全局事务、提交或回滚全局事务
  • RM（管理分支事务处理的资源）：与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

• Seata的2PC方案

  • 一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。
  • 二阶段：提交异步化，非常快速地完成。回滚通过一阶段的回滚日志进行反向补偿。
  • 一阶段本地事务提交前，需要确保先拿到 全局锁 。拿不到全局锁 ，不能提交本地事务。
  • 拿全局锁的尝试被限制在一定范围内，超出范围将放弃，并回滚本地事务，释放本地锁。
  • 在数据库本地事务隔离级别读已提交或以上的基础上，Seata（AT 模式）的默认全局隔离级别是 读未提交
  • 如果应用在特定场景下，必需要求全局的 读已提交 ，目前 Seata 的方式是通过 SELECT FOR UPDATE 语句的代理。

• Seata执行流程分析
  

  • 每个 RM 使用 DataSourceProxy 链接数据路，目的是使用 ConnectionProxy，使用数据源和数据代理的目的是在第一阶段将 undo_log 和业务数据放在一个本地事务提交，这样就保存了只要有业务操作就一定有 undo_log

  • 在第一阶段 undo_log 中存放了数据修改前后修改后的值，为事务回滚做好准别，所以第一阶段完成就已经将分支事务提交了，也就释放了锁资源

  • TM 开启全局事务开始，将 XID全局事务ID 放在事务上下文中，通过 feign 调用也将 XID 传入下游分支事务，每个分支事务将自己的 Branch ID 分支事务ID与 XID 关联

  • 第二阶段全局事务提交，TC会通知各分支参与者提交分支事务，在第一阶段就已经提交了分支事务，这里各参与者只需要删除undo_log即可，并且可以异步执行，第二阶段很快可以完成

  • 如果某一个分支事务异常，第二阶段就全局事务回滚操作，TC会通知各分支参与者回滚分支事务，通过 XID 和 Branch-ID 找到对应的回滚日志，通过回滚日志生成的反向SQL并执行，以完成分支事务回滚到之前