分布式事务

Lyndon1107

已于 2023-01-12 15:12:27 修改

阅读量445

点赞数

分类专栏：分布式文章标签：分布式

于 2022-12-28 23:16:56 首次发布

本文链接：https://blog.csdn.net/qq_19636353/article/details/128475272

版权

分布式专栏收录该内容

8 篇文章 0 订阅

订阅专栏

分布式事务

分布式事务往往会横跨多个资源管理器（Resource Manager，RM），并由分布式事务协调器（Distributed Transaction Coordinator，DTC）负责事务协调。分布式事务通常基于两段提交协议（Two-phase Commit, 2PC）实现：事务提交分两个阶段进行，在第一阶段（准备阶段）中，2PC协议需要确保DTC已经获得了所有来自RM的提交反馈信息，对于每个RM，DTC都需要明确知道它是否可以成功完成其本地事务，或者无法完成。就RM而言，在这一阶段会尝试提交其本地事务，如果能够成功提交，则向DTC报告“可以提交”的状态，否则报告“无法提交”的状态。DTC在收集了所有参与者RM的状态后，如果全部为“可以提交”，则启动第二阶段（提交阶段），通知所有RM完成正式提交；但只要有一个RM报告“无法提交”，则DTC会通知其它的RM取消提交操作。

分布式事务解决方案4

1、seata 2、消息队列 3、saga 4、XA

分布式事务在实现上分为基于补偿的方案和基于消息通知方案两种类型。
基于补偿的方案有2PC、TCC模式、Saga模式、Seata AT模式，它们都可以看成是遵守XA协议或是XA协议的。

两阶段提交（2PC）

两阶段提交又称2PC（two-phase commit protocol）,2pc是一个非常经典的强一致、中心化的原子提交协议。这里所说的中心化是指协议中有两类节点：一个是中心化协调者节点（coordinator）和N个参与者节点（partcipant）。
在这里插入图片描述

Seata

Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。
Seata 是 Simple Extensible Autonomous Transaction Architecture 的简写，由 feascar 改名而来。

Seata官网 https://seata.io/zh-cn/docs/user/configuration/nacos.html

Seata三大组件

TC：Transaction Coordinator事务协调器，管理全局的分支事务的状态，用于全局性事务的提交和回滚
TM：Transaction Manager 事务管理器，用户开启、提交或者回滚【全局事务】
RM：Resource Manager资源管理器，用于分支事务上的资源管理，向TC注册分支事务，上报分支事务的状态，接收TC的命令来提交或者回滚分支事务
传统XA协议实现2PC方案的RM是在数据库层，RM本质上就是数据库自身
Seata的RM是以jar包的形式嵌入在应用程序里面

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

XID

TM请求TC开启一个全局事务，TC会生成一个XID作为该全局事务的编号XID，XID会在微服务的调用链路中传播，保证将多个微服务对的子事务关联在一起

Seata 的工作过程

TM 请求 TC，开始一个新的全局事务，TC 会为这个全局事务生成一个 XID。
XID 通过微服务的调用链传递到其他微服务。
RM 把本地事务作为这个XID的分支事务注册到TC。
TM 请求 TC 对这个 XID 进行提交或回滚。
TC 指挥这个 XID 下面的所有分支事务进行提交、回滚。

AT模式 (Auto Transaction)

AT 模式是一种无侵入的分布式事务解决方案。在 AT 模式下，用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作。

TCC模式

TCC需要注意三种异常处理分别是空回滚、幂等、悬挂：

TCC是Try、Confirm、Cancel三个词语的缩写，TCC要求每个分支事务实现三个操作：预处理Try、确认Confirm、撤销Cancel。Try操作做业务检查及资源预留，Confirm做业务确认操作，Cancel实现一个与Try相反的操作既回滚操作。TM首先发起所有的分支事务的try操作，任何一个分支事务的try操作执行失败，TM将会发起所有分支事务的Cancel操作，若try操作全部成功，TM将会发起所有分支事务的Confirm操作，其中Confirm/Cancel操作若执行失败，TM会进行重试。

Saga模式：跨服务的事务处理

在微服务架构中，事务处理往往会横跨多个服务，这就难免会需要依赖于服务间的通信机制。微服务间的通信分同步和异步，而异步通信才是更为推荐的方案：在设计微服务架构时，应该尽可能地选择异步方式来实现服务间通信，这样才能更好地实现服务间解耦。就事务处理而言，由于它并不是一个瞬时操作，而是一个长时运行的任务（long-running process），因此更适合采用异步方式来完成。Saga模式所解决的问题就是这种基于异步消息机制的跨服务事务处理，它的基本过程是，每个微服务自己处理本地事务，然后根据处理结果向消息队列派发消息以便整个事务能够进行下一步的处理，与此同时，微服务还会侦听来自于其它微服务的消息，来决定自己是否需要进行事务补偿（Compensation）。当一个Saga事务被启动后，它会一步一步地执行其中的每一个步骤（Saga Step）。在每一个步骤中，有且仅有一个微服务实例的参与者负责其本地事务的执行，当所有的步骤全部成功完成后，Saga事务也就成功提交了。当然，如果其中有某个步骤执行失败，那么之前成功的本地事务就应该回滚，否则无法保证数据一致性。由于此刻已成功的本地事务已经无法回滚，所以，在Saga模式中，一般都会通过补偿操作来实现本地事务回滚的效果。整个流程大致可以使用下面的流程图表示：

一般会有两种方式来实现Saga模式：编排式和协调式。

Saga体系结构模式：微服务架构下跨服务事务的实现
https://blog.csdn.net/sD7O95O/article/details/125240562