1. 什么是反向补偿首先来和大家解释一个名词大家在看分布式事务相关资料的时候经常会看到一个名词反向补偿。啥是反向补偿呢我举一个例子假设我们现在有三个微服务分别是 A、B、C现在在 A 服务中分别调用 B 和 C 服务为了确保 B 和 C 同时成功或者同时失败我们需要使用到分布式事务。但是按照我们之前对本地事务的理解B 和 C 中的本地事务当 B 服务中的事务执行完毕并且提交之后现在 C 服务中的事务出现异常需要回滚了但是B 已经提交了还怎么回滚呀此时我们所说的回滚其实并不是传统意义上的通过 MySQL redo log 日志来回滚的那种而是通过一条更新 SQL再把 B 服务中已经更改过的数据复原。这就是我们所说的反向补偿2. 基本概念梳理Seata 中有三个核心概念TC (Transaction Coordinator) - 事务协调者维护全局和分支事务的状态驱动全局事务提交或回滚。TM (Transaction Manager) - 事务管理器定义全局事务的范围开始全局事务、提交或回滚全局事务。RM ( Resource Manager ) - 资源管理器管理分支事务处理的资源( Resource )与 TC 交谈以注册分支事务和报告分支事务的状态并驱动分支事务提交或回滚。其中TC 为单独部署的 Server 服务端TM 和 RM 为嵌入到应用中的 Client 客户端。我们来看如下一张图片这张图基本上把这个三个概念解释清楚了。其实不看这张图我们大概也能猜到分布式事务的实现原理首先得有一个全局的事务协调者TC各个本地事务RM在开始执行的时候或者在执行的过程中及时将自己的状态报告给全局事务协调者这个全局事务协调者知道每一个分支事务目前的执行状态当他TC发现所有的本地事务都执行成功的时候就通知大家一起提交当他发现在本次事务中有人执行失败的时候就通知大家一起回滚当然这个回滚不一定是真的回滚而是反向补偿。那么一个事务什么时候开始什么时候结束呢也就是事务的边界在哪里seata 中的分布式事务都是通过GlobalTransactional注解来实现的换句话说这个注解该加在哪里添加该注解的地方其实就是事务管理器 TM 了。经过上面的介绍小伙伴们应该明白了其实用 Seata 实现分布式事务没有想象的那么难原理还是非常 Easy 的。Seata 中涉及到四种不同的模式接下来介绍的四种不同模式其实都是在说当有一个本地事务失败的时候该如何回滚这就是我们后面要说的四种不同的分布式事务模式了。3. 什么是两阶段提交先来看下面一张图这张图里涉及到三个概念AP这个不用多说AP 就是应用程序本身。RMRM 是资源管理器也就是事务的参与者大部分情况下就是指数据库一个分布式事务往往涉及到多个 RM。TMTM 就是事务管理器创建分布式事务并协调分布式事务中的各个子事务的执行和状态子事务就是指在 RM 上执行的具体操作。那么什么是两阶段(Two-Phase Commit, 简称 2PC)提交两阶段提交说白了道理很简单松哥举个简单例子来和大家说明两阶段提交比如下面一张图我们在 Business 中分别调用 Storage 与 Order、Account这三个中的操作要同时成功或者同时失败但是由于这三个分处于不同服务因此我们只能先让这三个服务中的操作各自执行三个服务中的事务各自执行就是两阶段中的第一阶段。第一阶段执行完毕后先不要急着提交因为三个服务中有的可能执行失败了此时需要三个服务各自把自己一阶段的执行结果报告给一个事务协调者事务协调者收到消息后如果三个服务的一阶段都执行成功了此时就通知三个事务分别提交如果三个服务中有服务执行失败了此时就通知三个事务分别回滚。这就是所谓的两阶段提交。总结一下两阶段提交中事务分为参与者例如上图的各个具体服务与协调者参与者将操作成败通知协调者再由协调者根据所有参与者的反馈情报决定各参与者是要提交操作还是中止操作这里的参与者可以理解为 RM协调者可以理解为 TM。不过 Seata 中的各个分布式事务模式基本都是在二阶段提交的基础上演化出来的因此并不完全一样这点需要小伙伴们注意。4. AT 模式AT 模式是一种全自动的事务回滚模式。整体上来说AT 模式是两阶段提交协议的演变一阶段业务数据和回滚日志记录在同一个本地事务中提交释放本地锁和连接资源。二阶段则分两种情况2.1 提交异步化非常快速地完成。2.2 回滚通过一阶段的回滚日志进行反向补偿。大致上的逻辑就是上面这样我们通过一个具体的案例来看看 AT 模式是如何工作的假设有一个业务表 product如下现在我们想做如下一个更新操作update productsetnameGTSwhere nameTXC;步骤如下一阶段解析 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注解就行了。其他的提交呀回滚呀都是全自动的比较省事。所以如果你项目中选择了用 seata 来处理分布式事务那么用 AT 模式的概率还是相当高的。5. TCC 模式TCCTry-Confirm-Cancel 模式就带一点手动的感觉了它也是两阶段但是和 AT 又不太一样我们来看下流程。官网上有一张 TCC 的流程图我们来看下可以看到TCC 也是分为两阶段第一阶段是 prepare在这个阶段主要是做资源的检测和预留工作例如银行转账这个阶段就先去检查下用户的钱够不够不够就直接抛异常够就先给冻结上。第二阶段是 commit 或 rollback这个主要是等各个分支事务的一阶段都执行完毕都执行完毕后各自将自己的情况报告给 TCTC 一统计发现各个分支事务都没有异常那么就通知大家一起提交如果 TC 发现有分支事务发生异常了那么就通知大家回滚。那么小伙伴可能也发现了上面这个流程中一共涉及到了三个方法prepare、commit 以及 rollback这三个方法都完全是用户自定义的方法都是需要我们自己来实现的所以我一开始就说 TCC 是一种手动的模式。和 AT 相比大家发现 TCC 这种模式其实是不依赖于底层数据库的事务支持的也就是说哪怕你底层数据库不支持事务也没关系反正 prepare、commit 以及 rollback 三个方法都是开发者自己写的我们自己将这三个方法对应的流程捋顺就行了。6. XA 模式如果小伙伴们懂得 MySQL 数据库的 XA 事务那么一下子就懂得 seata 中的 XA 模式是咋回事了。XA 规范是 X/Open 组织定义的分布式事务处理DTPDistributed Transaction Processing标准。XA 规范描述了全局的事务管理器与局部的资源管理器之间的接口。 XA规范的目的是允许的多个资源如数据库应用服务器消息队列等在同一事务中访问这样可以使ACID属性跨越应用程序而保持有效。XA 规范使用两阶段提交来保证所有资源同时提交或回滚任何特定的事务。XA 规范在上世纪 90 年代初就被提出。目前几乎所有主流的数据库都对 XA 规范提供了支持。XA 事务的基础是两阶段提交协议。需要有一个事务协调者来保证所有的事务参与者都完成了准备工作(第一阶段)。如果协调者收到所有参与者都准备好的消息就会通知所有的事务都可以提交了第二阶段。MySQL 在这个 XA 事务中扮演的是参与者的角色而不是协调者(事务管理器)。MySQL 的 XA 事务分为内部 XA 和外部 XA。外部 XA 可以参与到外部的分布式事务中需要应用层介入作为协调者内部 XA 事务用于同一实例下跨多引擎事务由 Binlog 作为协调者比如在一个存储引擎提交时需要将提交信息写入二进制日志这就是一个分布式内部 XA 事务只不过二进制日志的参与者是 MySQL 本身。 MySQL 在 XA 事务中扮演的是一个参与者的角色而不是协调者。换言之MySQL 天然的就可以通过 XA 规范来实现分布式事务只不过需要借助一些外部应用的支持。我们来看下 Seata 中的 XA 模式使用流程。先来看一张来自官方的图片可以看到这也是一个两阶段提交一阶段业务 SQL 操作放在 XA 分支中进行XA 分支完成后执行 XA prepare由 RM 对 XA 协议的支持来保证持久化即之后任何意外都不会造成无法回滚的情况。二阶段分两种情况提交或者回滚分支提交执行 XA 分支的 commit分支回滚执行 XA 分支的 rollback和前面两种模式的区别在于XA 模式中的回滚是正儿八经的回滚是我们传统意义上所理解的回滚而不是一种反向补偿。7. Saga 模式最后再来看看 saga 模式这种模式应用很少大家作为了解即可。saga 模式是 seata 提供的长事务解决方案然而长事务是我们在开发中应该避免的因为效率低并且容易造成死锁。这个 saga 模式就有点像流程引擎开发者先自己画一个流程引擎把整个事务中涉及到的方法都囊括进来每一个方法返回什么的时候就是正常的返回什么就是异常的正常的就继续往下走异常的就执行另一套流程也就是我们需要提前准备好两套方法第一套是各种正常情况的执行流程第二套则是发生异常之后的执行流程类似下面这样绿色的都是正常的流程红色的则是发生异常后回滚的流程。回滚中也是一种反向补偿。