这篇文章主要讲解了“Java Spring Boot分布式事务问题怎么解决”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“Java Spring Boot分布式事务问题怎么解决”吧！
首先，来和大家解释一个名词，大家在看分布式事务相关资料的时候，经常会看到一个名词：反向补偿。啥是反向补偿呢？
我举一个例子：假设我们现在有三个微服务分别是 A、B、C，现在在 A 服务中分别调用 B 和 C 服务，为了确保 B 和 C 同时成功或者同时失败，我们需要使用到分布式事务。但是按照我们之前对本地事务的理解，B 和 C 中的本地事务，当 B 服务中的事务执行完毕并且提交之后，现在 C 服务中的事务出现异常需要回滚了，但是，B 已经提交了还怎么回滚呀？
此时我们所说的回滚其实并不是传统意义上的，通过 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 了。
经过上面的介绍，小伙伴们应该明白了，其实用 Seata 实现分布式事务没有想象的那么难，原理还是非常 Easy 的。
Seata 中涉及到四种不同的模式，接下来介绍的四种不同模式，其实都是在说当有一个本地事务失败的时候，该如何回滚？这就是我们后面要说的四种不同的分布式事务模式了。
先来看下面一张图：
这张图里涉及到三个概念：
AP：这个不用多说，AP 就是应用程序本身。
RM：RM 是资源管理器，也就是事务的参与者，大部分情况下就是指数据库，一个分布式事务往往涉及到多个 RM。
TM：TM 就是事务管理器，创建分布式事务并协调分布式事务中的各个子事务的执行和状态，子事务就是指在 RM 上执行的具体操作。
那么什么是两阶段(Two-Phase Commit, 简称 2PC)提交？
两阶段提交说白了道理很简单，松哥举个简单例子来和大家说明两阶段提交：
比如下面一张图：
我们在 Business 中分别调用 Storage 与 Order、Account，这三个中的操作要同时成功或者同时失败，但是由于这三个分处于不同服务，因此我们只能先让这三个服务中的操作各自执行，三个服务中的事务各自执行就是两阶段中的第一阶段。
第一阶段执行完毕后，先不要急着提交，因为三个服务中有的可能执行失败了，此时需要三个服务各自把自己一阶段的执行结果报告给一个事务协调者，事务协调者收到消息后，如果三个服务的一阶段都执行成功了，此时就通知三个事务分别提交，如果三个服务中有服务执行失败了，此时就通知三个事务分别回滚。
这就是所谓的两阶段提交。
总结一下：两阶段提交中，事务分为参与者（例如上图的各个具体服务）与协调者，参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是要提交操作还是中止操作，这里的参与者可以理解为 RM，协调者可以理解为 TM。
不过 Seata 中的各个分布式事务模式，基本都是在二阶段提交的基础上演化出来的，因此并不完全一样，这点需要小伙伴们注意。
AT 模式是一种全自动的事务回滚模式。
整体上来说，AT 模式是两阶段提交协议的演变：
一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。
二阶段则分两种情况：2.1 提交异步化，非常快速地完成。2.2 回滚通过一阶段的回滚日志进行反向补偿。
大致上的逻辑就是上面这样，我们通过一个具体的案例来看看 AT 模式是如何工作的：
假设有一个业务表 product，如下：
现在我们想做如下一个更新操作：
update product set name = 'GTS' where name = 'TXC';
步骤如下：
一阶段：
解析 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 模式的概率还是相当高的。
TCC（Try-Confirm-Cancel） 模式就带一点手动的感觉了，它也是两阶段，但是和 AT 又不太一样，我们来看下流程。
官网上有一张 TCC 的流程图，我们来看下：
可以看到，TCC 也是分为两阶段：
第一阶段是 prepare，在这个阶段主要是做资源的检测和预留工作，例如银行转账，这个阶段就先去检查下用户的钱够不够，不够就直接抛异常，够就先给冻结上。
第二阶段是 commit 或 rollback，这个主要是等各个分支事务的一阶段都执行完毕，都执行完毕后各自将自己的情况报告给 TC，TC 一统计，发现各个分支事务都没有异常，那么就通知大家一起提交；如果 TC 发现有分支事务发生异常了，那么就通知大家回滚。
那么小伙伴可能也发现了，上面这个流程中，一共涉及到了三个方法，prepare、commit 以及 rollback，这三个方法都完全是用户自定义的方法，都是需要我们自己来实现的，所以我一开始就说 TCC 是一种手动的模式。
和 AT 相比，大家发现 TCC 这种模式其实是不依赖于底层数据库的事务支持的，也就是说，哪怕你底层数据库不支持事务也没关系，反正 prepare、commit 以及 rollback 三个方法都是开发者自己写的，我们自己将这三个方法对应的流程捋顺就行了。
如果小伙伴们懂得 MySQL 数据库的 XA 事务，那么一下子就懂得 seata 中的 XA 模式是咋回事了。
XA 规范是 X/Open 组织定义的分布式事务处理（DTP，Distributed 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 模式中的回滚，是正儿八经的回滚，是我们传统意义上所理解的回滚，而不是一种反向补偿。
最后再来看看 saga 模式，这种模式应用很少，大家作为了解即可。
saga 模式是 seata 提供的长事务解决方案，然而长事务是我们在开发中应该避免的，因为效率低并且容易造成死锁。
这个 saga 模式就有点像流程引擎，开发者先自己画一个流程引擎，把整个事务中涉及到的方法都囊括进来，每一个方法返回什么的时候就是正常的，返回什么就是异常的，正常的就继续往下走，异常的就执行另一套流程，也就是我们需要提前准备好两套方法，第一套是各种正常情况的执行流程，第二套则是发生异常之后的执行流程，类似下面这样：
绿色的都是正常的流程，红色的则是发生异常后回滚的流程。回滚中也是一种反向补偿。
感谢各位的阅读，以上就是“Java Spring Boot分布式事务问题怎么解决”的内容了，经过本文的学习后，相信大家对Java Spring Boot分布式事务问题怎么解决这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
