Java开发 - 不知道算不算详细的分布式事务详解

关注

原创 2023-05-24 19:53:13 1.4k 阅读 AI 写同款· GEO 优化 ›

Java分布式事务 事务发起方发送消息到消息队列：// 将消息发送到消息队列// ...事务消费方接收和处理消息：try {// 处理消息的业务逻辑// ...// 消息处理成功，确认消费// 消息处理失败，取消消费，进行补偿或重试// 确认消费成功，将消息标记为已处理// ...// 取消消费，将消息标记为未处理或重新放回消息队列// ... 阅读详情

前言

前日对JUC进行了一个深度总结，不过现在博主能记得的也不多了，只是这东西，不是看几遍写几遍就能完全记住的，功夫在平时，很多知识点都需要反复的看，不光要看，还要用，这样才能了解其原理，掌握其原理，从而能更好的运用于平时的开发中，提高开发效率。今天给大家带来一篇分布式事务相关的总结，详不详细的不敢说，大家还是自己来看看吧。

事务

虽然我们说的是分布式事务，但在这之前，我们还是要了解一下事务的本质，事务分为两种，一种是我们本篇要说的分布式事务，另一种是本地事务。下面，我们对这两种事务的特点进行说明。

本地事务

本地事务也叫做单机事务。但说起来和单机游戏并不一样，它只是相对于分布式事务的一种描述。学完此篇，相信你对单机事务的理解能够加深不少。

本地事务由四大特点，俗称ACID，分别是：

A：原子性，即事务中的所有操作，要么全部成功，要么全部失败；
C：一致性，即要保证数据库内部的完整性约束，声明性约束。也就是说，在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作；
I：隔离性，即对同一资源操作的事务不能同时发生，比如不能喝水的同时还在唱歌，你可以试试看；
D：持久性，即数据库的这些操作必须永久保存，不论对错。

分布式事务

分布式事务指的是在多个服务或多个数据库架构下产生的事务，有跨数据源的分布式事务，也有跨服务的分布式事务，可能还有其他类型的分布式事务。最典型的案例就是生成订单的时候，在生成订单时，还要修改库存，如果是购物车下单还要删除购物车下单商品，如果账户可充值还要扣除账户余额，是不是很复杂？但这，就是分布式事务的一部分！

这时，你会发现，每一个服务都是一个单独的单机事务，他们共同组成了这个分布式事务，原子性要求他们要么全部成功，要么全部失败，但对于上图的情况，你很难保证原子性，ACID恐怕就无法保证了，而这就是分布式事务要解决的问题。

分布式事务的理论基础

为了解决分布式事务问题，诞生了一些用于解决分布式问题原子性的理论，分别是CAP原则和BASE理论，以及在他们基础上提出的最终解决思路。

CAP原则

CAP定理是在1998年，由加州大学的科学家Eric Brewer提出，主要有灿个特性，分别对照CAP：

C：一致性，即在分布式系统中的所有数据备份，在同一时刻数据要一致；
A：可用性，即在访问多个服务的任何节点时，都能得到相应，不论成功还是失败；
P：分区容错性，即系统中任意信息的丢失或失败不会影响系统的继续运作，其原理是，分布式系统中的某节点出现故障时，形成独立分区，分区即使形成，也要保证整个系统依然可以对外提供服务。

CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。关于这点，我们在解决思路上再说。大家看下下面的图，他们的关系如下：

但他们之间存在一个不可调和的矛盾，那就是P一定存在，因为谁也不敢100%保证不会发生服务器故障，这个没有任何争议。这就是我们要说的解决思路，暂且不提，继续往下说。

BASE理论

BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

BASE理论有三大特性，分别是：

BASE是Basically Available（基本可用）：分布式系统发生故障时，允许损失部分可用性，但要保证核心功能依然可用，其中，损失包括响应时间上的损失和非核心功能的损失；
Soft state（软状态）：在一定时间内，允许出现数据不一致的临时状态，称为软状态；
Eventually consistent（最终一致性）：在无法保证强一致性的条件下，在软状态结束后，要达到数据的最终一致性。

分布式事务解决思路

上面两个理论看完之后，相信你对解决思路已经有了一个大概的了解，总结起来就是两个模式：AP和CP：

AP：最终一致性模式，即各子事务分别执行和提交，允许出现软状态，然后采取弥补措施保证数据的最终一致性；
CP：强一致性模式，即各子事务执行后后想等待，要么全部成功，要么全部失败，失败后回滚。

但无论是AP还是CP，在执行的过程中都离不开一个很重要的东西，那就是事务的协调者TC，我们会在下面的Seata中讲到。在分布式系统下，子系统的事务就是分支事务，有关联的事务统称为全局事务。

Seata核心架构

关于Seata，其实博主在微服务那篇博客中讲到过，也有过使用的案例：Java开发 - 数风流人物，还看“微服务”

有兴趣的可以看看，也可以去搜下其他Seata相关的教程，了解Seata的可以继续往下看。关于Seata，博主就不再详细介绍了，我们直接切入正题，说说Seata的架构。

在Seata的事务管理中，有三个重要的角色，我们在上面已经提到了一个事务协调者TC，还有一个事务管理器TM和资源管理器RM。他们的作用如下：

TC：维护全局和分支事务的状态，说白了就是提交或者回滚，类似于接线员；
TM：定义了全局事务的范围，控制全局事务的开始，提交或者回滚，是真正的管理者；
RM：用于管理各分支事务的资源，比如向TC注册分支事务，向TC报告分支事务的状态，驱动分支事务的提交或者回滚，是个执行者。

三者的关系结构如下图：

Seata基于此架构又提出了四种用于解决分布式事务的方案：

XA：强一致性分阶段事务模式，强一致性虽有性能损耗，但却没有业务侵入；

AT：最终一致的分阶段事务模式，无业务侵入，是Seata的默认模式；

TCC：最终一致的分阶段事务模式，有业务侵入；

SAGA：长事务模式，有业务侵入。

Seata四大模式

XA模式

原始的XA 规范是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准，描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对 XA 规范提供了支持。

原始的XA其实是一种规范，目前的主流数据库都实现了次规范，其实现原理是基于两阶段提交：

第一阶段：

TC通知分支事务进行事务处理本地事务，并将执行结果上报TC，此过程只执行SQL，不提交，继续持有数据库锁。

第二阶段：

TC根据各分支事务上报的结果进行处理，如果全部执行成功，则通知所有分支事务进行提交，提交后锁释放；如果有一条以上的失败消息，则通知所有分支事务进行回滚，最终释放锁。

原始的XA请看下图：

Seata中的XA是在XA的基础上做了封装和改造，我们来看看其架构图，它和我们前面画的TM，TC，RM的关系图很像：

看图，其两个阶段都在做什么就一目了然了。

虽然XA模式实现简单，使用了强一致性，且没有代码的侵入，但和传统XA一样，第一阶段不提交，所以锁在第二阶段释放，性能略差，此模式也必须依赖关系型数据库才可以使用。

其实现也比较简单，分两步完成：

第一步，开启XA模式：

seata:
  data-source-proxy-mode: XA

第二步，给发起全局事务的入口方法添加@GlobalTransactional注解。

关于Seata的使用就不再详细说了，既然你看到这里，就代表Seata你至少是知道怎么用的，比如依赖和配置，不了解的可查看博主在上面放的微服务的链接或自行查找学习。

AT模式

AT模式前面提到过，是分阶段提交的事务模型，它主要解决了XA模式中资源锁定时间太久的问题，因此，它并不是强一致性的，而是最终一致性的，它对代码同样没有侵入，是Seata的默认模式。

下面，我们来看看它的架构流程图：

架构图很清晰，但也略微复杂，我们来画一个简易版的流程图：

这样，流程有没有更清晰一点？画图能省不少文字啊，不过画图确实比较费时间。

注意：这里存在一个问题，就是AT模式因为在第一阶段直接提交后释放的锁，第二阶段无法保证其他事务是否会操作同一条数据，所以会存在脏写的问题。

解决办法就是引入全局锁，在释放DB锁之前，先拿到全局锁，避免在同一时刻有另外一个事务来操作当前数据。这一点要格外注意。

目前使用全局锁@GlobalLock时，限制条件过于苛刻，必须要添加@Transaction注解，同时必须是for update语句，否则不会触发全局锁检查。更详细的大家在使用过程中再详细了解，本文不再延伸介绍。

使用AT模式也很简单：

seata:
  data-source-proxy-mode: AT # 默认就是AT

修改配置即可直接使用，详细代码不再给出，可参考：

详解 Seata AT 模式事务隔离级别与全局锁设计

Seata AT 模式

https://github.com/seata/seata-samples

TCC模式

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

Try：资源的检测和预留；
Confirm：完成资源操作业务，要求 Try 成功 Confirm 也一定能成功；
Cancel：预留资源释放，可以认为是回滚操作。

它和AT相比的优点是不依赖undolog，事务回滚通过资源的预留和cancel操作。其架构如下：

看起来和AT及其相似，只是没有了对undolog文件的操作，多了try，confirm和cancel操作。从图中，我们应该还能看出来一个问题，那就是TCC模式不依赖数据库事务，可用于非事务性数据库。

那么，你在上图还能看出有哪些问题呢？Let us see......

有两个问题需要格外注意：空回滚和事务悬挂。

空回滚

我们假设在try阶段发生了阻塞，这可能会导致全局事务超时，进而导致cancel操作被触发，在try操作没有执行的情况下，执行cancel的回滚操作就是空回滚。如果不对空回滚加以防范的话，可能会造成资源的无效释放，即在没有预留资源的情况下就释放资源，造成异常。

解决办法是：执行cancel操作时，应当判断try是否已经执行，如果尚未执行，则不应执行空回滚。

事务悬挂

对于已经空回滚的业务，之前被阻塞的try操作恢复，继续执行try，就永远不可能confirm或cancel ，事务一直处于中间状态，这就是业务悬挂。

解决办法是：执行try操作时，应当判断cancel是否已经执行过了，如果已经执行，应当阻止空回滚后的try操作，避免悬挂。

总结

总的来说，这俩其实算是一个问题，可以通过创建一张新表，字段自己随便定，只要每个事务不一样即可，推荐使用全局事务id，三个函数中的操作如下：

try中记录事务状态到表中；
confirm中根据全局事务id删除这条数据；
cancel中恢复记录表中的数据到初始状态；

判断空回滚方法：

cancel业务中，根据xid查询数据，如果为null则说明try还没做，可不执行空回滚，然后根据全局事务id插入一条状态数据留给try做空回滚判断；
try业务中，根据xid查询数据，如果已经全局事务id，则存在Cancel已经执行的情况，可拒绝执行try业务
以上两条满足一条即可，如果空回滚做了，try绝对不能执行，但若是经过判断避免了，那try继续，否则try执行了，真到了要执行cancel的时候是要正常执行的。

SAGA模式

Saga模式是SEATA提供的长事务解决方案，在Saga模式中，业务流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者，一阶段正向服务和二阶段补偿服务都由业务开发实现。

看图，分布式事务执行过程中，各节点依次执行正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任意一个正向操作执行失败，那么分布式事务会在当前节点，也就是FAILS的地方通过补偿服务退回去，执行前面各节点的逆向回滚操作，把已提交的节点的操作回滚，使分布式事务回到初始状态。

适用场景：

业务流程长、业务流程多
参与者包含其它公司或遗留系统服务，无法提供 TCC 模式要求的三个接口

优势：

一阶段提交本地事务，无锁，高性能
事件驱动架构，参与者可异步执行，高吞吐
补偿服务易于实现

缺点：

不保证隔离性，其实还是脏写问题
其软状态持续时间不可预测

关于Saga，更详细内容可见这里：Seata Saga 模式

博主个人感觉Sage模式是四大模式中最复杂的了，说实话，没用过，和前三种比起来，Saga更难理解，博主也没有理解透，惭愧惭愧！！！但有一点博主是明确的，其补偿服务是另类的回滚，可以通过一个单独的节点完成此操作。大家还是自己看吧，不要被误导，谁要是搞懂了回来给博主科普科普。

四大模式对比

	XA	AT	TCC	SAGA
一致性	强一致性	弱一致性	弱一致性	最终一致性
隔离性	完全隔离	基于全局锁隔离	基于资源预留隔离	无隔离
代码侵入	无	无	有，try，confirm，cancel	有，编写状态机和补偿服务
性能	差	好	非常好	非常好
使用场景	对一致性和隔离型要求高的事务	基于关系型数据库的大多数分布式事务场景都可以，比较通用	对性能要求高使用非关系型数据库的	业务流程长、业务流程多参与者包含其它公司或遗留系统服务，无法提供 TCC 模式要求的三个接口