基于seata的分布式事务

什么是反向补偿

• 假设我们现在有三个微服务分别是 A、B、C，现在在 A 服务中分别调用 B 和 C 服务，为了确保 B 和 C 同时成功或者同时失败，我们需要使用到分布式事务。但是按照我们之前对本地事务的理解，B 和 C 中的本地事务，当 B 服务中的事务执行完毕并且提交之后，现在 C 服务中的事务出现异常需要回滚了，此时的回滚并不是传统意义上的，通过 MySQL redo log 日志来回滚的那种，而是通过一条更新 SQL，再把 B 服务中已经更改过的数据复原。这就是我们所说的反向补偿！

seata基本概念

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

其中，TC 为单独部署的 Server 服务端，TM 和 RM 为嵌入到应用中的 Client 客户端

• 分布式事务实现原理
  • 首先得有一个全局的事务协调者（TC）
  • 各个本地事务（RM）在开始执行的时候，或者在执行的过程中，及时将自己的状态报告给全局事务协调者
  • 这个全局事务协调者知道每一个分支事务目前的执行状态
  • 当他（TC）发现所有的本地事务都执行成功的时候，就通知大家一起提交；当他发现在本次事务中，有人执行失败的时候，就通知大家一起回滚（当然这个回滚不一定是真的回滚，而是反向补偿）。
  • seata 中的分布式事务都是通过 @GlobalTransactional 注解来实现的，添加该注解的地方其实就是事务管理器 TM 了。

什么是两阶段提交

• AP：应用程序本身。
• RM：RM 是资源管理器，也就是事务的参与者，大部分情况下就是指数据库，一个分布式事务往往涉及到多个 RM。
• TM：TM 就是事务管理器，创建分布式事务并协调分布式事务中的各个子事务的执行和状态，子事务就是指在 RM 上执行的具体操作。

• 我们在 Business 中分别调用 Storage 与 Order、Account，这三个中的操作要同时成功或者同时失败，但是由于这三个分处于不同服务，因此我们只能先让这三个服务中的操作各自执行，三个服务中的事务各自执行就是两阶段中的第一阶段。

• 第一阶段执行完毕后，三个服务中有的可能执行失败了，此时需要三个服务各自把自己一阶段的执行结果报告给一个事务协调者，事务协调者收到消息后，如果三个服务的一阶段都执行成功了，此时就通知三个事务分别提交，如果三个服务中有服务执行失败了，此时就通知三个事务分别回滚。

• 这就是所谓的两阶段提交。

总结

• 两阶段提交中，事务分为参与者（例如上图的各个具体服务）与协调者，参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是要提交操作还是中止操作，这里的参与者可以理解为 RM，协调者可以理解为 TM。

seata提供的四种模式

Seata 中的各个分布式事务模式，基本都是在二阶段提交的基础上演化出来的，因此并不完全一样

AT模式

• AT 模式是一种全自动的事务回滚模式。整体上来说，AT 模式是两阶段提交协议的演变
  • 一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。
  • 二阶段则分两种情况： 提交异步化，非常快速地完成。或者回滚通过一阶段的回滚日志进行反向补偿。
• 示例

假设有个业务表product

执行如下更新操作

update product set name = 'GTS' where name = 'TXC';
1

步骤

• 一阶段
  • 解析 SQL：得到 SQL 的类型（UPDATE），表（product），条件（where name = ‘TXC’）等相关的信息。
  • 查询前镜像：根据解析得到的条件信息，生成查询语句，定位数据（查找到更新之前的数据）。
  • 执行上面的更新 SQL。
  • 查询后镜像：根据前镜像的结果，通过主键定位数据。
  • 插入回滚日志：把前后镜像数据以及业务 SQL 相关的信息组成一条回滚日志记录，插入到 UNDO_LOG 表中。
  • 提交前，向 TC 注册分支：申请 product 表中，主键值等于 1 的记录的 全局锁。
  • 本地事务提交：业务数据的更新和前面步骤中生成的 UNDO LOG 一并提交。
  • 将本地事务提交的结果上报给 TC。
• 二阶段
  • 回滚步骤
    • 首先收到 TC 的分支回滚请求，开启一个本地事务，执行如下操作。
    • 通过 XID 和 Branch ID 查找到相应的 UNDO LOG 记录（这条记录中保存了数据修改前后对应的镜像）。
    • 数据校验：拿 UNDO LOG 中的后镜像与当前数据进行比较，如果有不同，说明数据被当前全局事务之外的动作做了修改。这种情况，需要根据配置策略来做处理。
    • 根据 UNDO LOG 中的前镜像和业务 SQL 的相关信息生成并执行回滚的语句：update product set name = ‘TXC’ where id = 1;
    • 提交本地事务。并把本地事务的执行结果（即分支事务回滚的结果）上报给 TC。
  • 提交步骤
    • 收到 TC 的分支提交请求，把请求放入一个异步任务的队列中，马上返回提交成功的结果给 TC。
    • 异步任务阶段的分支提交请求将异步和批量地删除相应 UNDO LOG 记录。

总结

• 当你要更新一条记录的时候，系统将这条记录更新之前和更新之后的内容生成一段 JSON 并存入 undo log 表中，将来要回滚的话，就根据 undo log 中的记录去更新数据（反向补偿），将来要是不回滚的话，就删除 undo log 中的记录。
• 在整个过程中，开发者只需要额外创建一张 undo log 表就行了，然后给需要处理全局事务的地方加上 @GlobalTransactional 注解就行了。其他的提交回滚都是全自动的

TCC模式

TCC（Try-Confirm-Cancel） 模式也是两阶段

如图

• 第一阶段是 prepare，在这个阶段主要是做资源的检测和预留工作
  • 例如银行转账，这个阶段就先去检查下用户的钱够不够，不够就直接抛异常，够就先给冻结上。
• 第二阶段是 commit 或 rollback
  • 这个主要是等各个分支事务的一阶段都执行完毕，都执行完毕后各自将自己的情况报告给 TC。
  • TC 统计后，发现各个分支事务都没有异常，那么就通知大家一起提交；如果 TC 发现有分支事务发生异常了，那么就通知大家回滚。

总结

• prepare、commit 以及 rollback，这三个方法都完全是用户自定义的方法，都是需要我们自己来实现的，是一种手动的模式。
• 和 AT 相比， TCC 模式是不依赖于底层数据库的事务支持的，也就是说，哪怕你底层数据库不支持事务也没关系， prepare、commit 以及 rollback 三个方法都是开发者自己写的，我们自己将这三个方法对应的流程捋顺就行了。

XA模式

mysql中的XA事务

• XA 规范描述了全局的事务管理器与局部的资源管理器之间的接口。
• XA规范的目的是允许的多个资源（如数据库，应用服务器，消息队列等）在同一事务中访问，这样可以使 ACID 属性跨越应用程序而保持有效。
• XA 规范使用两阶段提交来保证所有资源同时提交或回滚任何特定的事务。
• XA 事务的基础是两阶段提交协议。需要有一个事务协调者来保证所有的事务参与者都完成了准备工作(第一阶段)。如果协调者收到所有参与者都准备好的消息，就会通知所有的事务都可以提交了（第二阶段）。
• MySQL 在这个 XA 事务中扮演的是参与者的角色，而不是协调者(事务管理器)。
• MySQL 的 XA 事务分为内部 XA 和外部 XA。
  • 外部 XA 可以参与到外部的分布式事务中，需要应用层介入作为协调者
  • 内部 XA 事务用于同一实例下跨多引擎事务，由 Binlog 作为协调者
  • 比如在一个存储引擎提交时，需要将提交信息写入二进制日志，这就是一个分布式内部 XA 事务，只不过二进制日志的参与者是 MySQL 本身。MySQL 在 XA 事务中扮演的是一个参与者的角色，而不是协调者。
• MySQL 天然的就可以通过 XA 规范来实现分布式事务，只不过需要借助一些外部应用的支持。

Seata 中的 XA 模式

XA也是二阶段提交

• 一阶段：业务 SQL 操作放在 XA 分支中进行，XA 分支完成后，执行 XA prepare，由 RM 对 XA 协议的支持来保证持久化（即之后任何意外都不会造成无法回滚的情况）。
• 二阶段分提交或者回滚：
  • 分支提交：执行 XA 分支的 commit
  • 分支回滚：执行 XA 分支的 rollback

和前面两种模式的区别在于，XA 模式中的回滚，是正儿八经的回滚，是我们传统意义上所理解的回滚，而不是一种反向补偿。

Saga模式

这种模式应用很少，作为了解即可。

• saga 模式是 seata 提供的长事务解决方案
• 然而长事务是我们在开发中应该避免的，因为效率低并且容易造成死锁。
• saga 模式就有点像流程引擎
  • 开发者先自己画一个流程引擎，把整个事务中涉及到的方法都囊括进来
  • 每一个方法返回什么的时候就是正常的，返回什么就是异常的，正常的就继续往下走，异常的就执行另一套流程
  • 也就是我们需要提前准备好两套方法，第一套是各种正常情况的执行流程，第二套则是发生异常之后的执行流程
  • 如下图

• 绿色的都是正常的流程，红色的则是发生异常后回滚的流程。
• 回滚中也是一种反向补偿。

总结

• 对于分布式事务来说，更多考虑的是原子性
• 隔离性绝大多数场景不考虑，解决的成本可能会比问题本身更复杂
• 互联网场景下，性能的要求往往比一致性更高，所以一般采用弱一致的解决方案
• 分布式事务选型
  • 事务回滚型。
    • 对于下单链路
    • 包含订单的更新和库存的扣减。先更新状态，后扣减库存，库存扣减失败后不断重试扣减库存意义不大，因为它可能本身就没有库存了，再怎么重试也没有库存了，只会增加开销。
    • 所以这种场景选择把订单状态回滚回去成功率更高。
  • 努力通知型
    • 对于物流类场景
    • 假设已经发货完成，需要更新订单状态，更新订单状态失败，这时候不断重试是没有问题的，因为更新状态没有什么资源争抢
• 极端情况
  • 假设订单已经执行成功。本地机器FullGC，没有写流水表，但是上游的回退或者重试消息已经过来了，他可能认为你本地没有执行成功，所以就忽略掉了，
  • 这种情况可以参考延迟双删策略(非常不优雅)。
  • 针对这种情况可以了解风险的存在，不建议对此进行过度设计

人工兜底

• 不管是回退还是重试，都可以采用MQ
• 用MQ的几个好处是解耦，异步，有一定的堆积能力
• 大部分MQ支持重试，重试进行一定次数放入死信队列，对于死信队列中因为逻辑导致的一直重试不成功，就需要人工介入了
• 使用MQ可能遇到的极端场景
  • 本地事务已经执行成功，但是没有发消息，可能因为机器挂掉了造成了不一致
  • 解决方案
    • 使用本地事务+消息表，再用一个定时任务不断的轮询消息表，重试一定次数
    • 失败一定次数后，发通知告警，后台页面展示这些消息，允许手动重试

分布式事务没有完美的解决方案，尽量在服务拆分的时候，把原子性的操作放在单进程，单数据库里处理，由本地事务保证ACID