别再说你不知道分布式事务了

发布时间：2025-11-05 12:26:32 来源：码上建站 作者：系统运维

简介

我们都知道 Seata 是别再一个分布式事务的解决方案，今天我们就来带大家了解一下什么是说不式事分布式事务，首先我们先来了解一下基础的知道知识——事务，我们先来了解一下事务的分布概念是什么。

基本概念

事务四部分构成— ACID：

事务分为两部分：本地事务和分布式事务。

在计算机系统中，比较多的是通过关系型数据库来控制事务，这是利用数据库本身的事务特性进行实现的，因为应用主要靠关系型数据库来维持事务，加上数据库和应用都在同一个服务器，所以基于关系型数据的事务又被称为本地事务。

分布式事务是指事务的亿华云参与者、支持事务的服务器、资源服务器以及事务管理者分别位于不同的分布式系统的不同节点之上，且属于不同的应用，分布式事务需要保证这些操作要么全部成功，要么全部失败，分布式事务就是为了保证在不同服务器上数据库数据的一致性。

Seata 的设计思路是将多个服务器的本地事务组成一个全局事务，下面若干个本地事务，都能满足ACID，最好形成一个整的分布式事务，操作分布式事务就像是操作本地事务一样。

分布式系统会把一个应用拆分为多个可独立部署的服务，服务于服务之间通常需要远程协作才能完成事务的操作，这种分布式系统环境下由于不同的服务之间通过网络远程协作完成的事务被称为分布式事务，例如供应链系统中，订单创建（生成订单、扣减库存、网站模板履约通知发货）等。

在上图中我们可以看出，只要涉及到操作多个数据源，就会产生事务的问题，我们在实际开发中应该要避免这这个你问题的出现，但是虽然系统的拓展，应用和应用之间必然会产生应用之间事务的分离，当微服务架构中，主要有MQ和Seata，在了解他们之前，我们先来了解一下分布式事务是怎样组成，以及如何实现的。

分布式事务

分布式事务指的是事务的参与者，支持事务的服务器，资源服务器分别位于分布式系统的不同节点之上，通常一个分布式事物中会涉及到对多个数据源或业务系统的操作。

随着互联网的发展，从之前的单一项目逐渐向分布式服务做转换，现如今微服务在各个公司已经普遍存在，而当时的本地事务已经无法满足分布式应用的要求，因此分布式服务之间事务的协调就产生了问题，如果做到多个服务之间事务的操作，能够像本地事务一样遵循ACID原则，成为一个难题，但是在大牛们不断的探索下，终于找到了分布式事务存在两大理论依据：CAP定律和BASE理论。

CAP定律

CAP定律由一致性(C)、可用性(A)、分区容错性(P)组成，在分布式系统中，不可能同时满足Consistency(一致性)/Availability(可用性)/Partition tolerance(分区容错性) 三个特性，最多只能同时满足其中两项。

在上图中我们可以看到，当我们用户去购物车里面点击下单结算的时候，首先会经过我们库存服务，判断库存是否足够，当库存满足，扣减库存以后，我们需要将数据同步到其他服务器上，这一步是为了保证数据的结果的一致性，这个时候如果网络产生波动了，我们的系统需要保证分区容错性，也就是我们必须容忍网络所带来的一些问题，此时想保证一致性，就需要舍弃可用性。

但是如果为了保证高可用性，那么在高并发的情况下，是无法保证在限定时间内给出响应，由于网络的不可靠，我们的订单服务可能无法拿到最新的数据，但是我们要给用户做出响应，那么也无法保证一致性，所以AP是无法保证强一致性的。

如果既想要保证高可用又想要保证一致性，必须在网络良好的情况下才能实现，那么解决方法只有一个，那就是需要将库存、订单、履约放到一起，但是这个就上去了我们微服务的作用，也就不再是分布式系统了。

在分布式系统中，分区容错性是必须存在的，我们只能在一致性和可用性上取舍，在这种条件下就诞生了BASE理论。

BASE理论

BASE由 基本可用 (Basically Available)、软状态 (Soft state)和 最终一致性 (Eventually consistent) 三个构建而成，是对CAP中一致性和可用性权衡的结果，来源于对互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的，核心四系那个是及时无法做到强一致性，但是每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

基本可用的意思是，对于我们的核心服务是可以使用的，其他的服务可以适当的降低响应时间，甚至是进行服务降级处理，在当前中，库存和订单肯定是核心服务，至于我们的发货系统在当时只要保证基本可用就行，它的同步可以慢一点或者延迟更高，等待流量高峰过去以后，在进行恢复。

软状态的意思是说，当我们大量下单的时候，扣减库存时，流量激增，这个时候如果大量访问到库存或者订单中，可能会将系统弄垮，这个过程中我们可以允许数据的同步存在延迟，不影响整体系统的使用。

经过流量高峰期以后，经过一段时间的同步，从中间状态最后变成数据最终一致性，保证各个服务数据的一致性。

二阶段提交(2PC)

2PC即两阶段提交协议，是将整个事务流程分为两个阶段，P是指准备阶段，C是指提交阶段。

就好比我们去KCC买冰淇淋吃，那刚好有活动，第二杯半价，但是你是一个人，这个时候刚好有个小姐姐过来，正在考虑买不买冰淇淋吃，这个时候你和她提出了AA，也就会说只有当你和她都同意买这个的时候，才能购买到，如果两个人中有一个不同意那么就不能买这个冰淇淋吃。

阶段一：准备阶段 老板要求你先进行付款，你同意付款完成后，再要求女方付款，女方同意付款完成。

阶段二：提交阶段 都付款完成，老板出餐，两个人都吃到冰淇淋。

这个例子就组成了一个事务。如果男女双方有一个人拒绝付款，那么老板就不会出餐，并且会把已收取的钱原路退回。

整个事务过程是由事务管理器和参与者组成的，店老板就是事务管理器，你和那个女孩就是参与者，事务管理器决策整个分布式事务在计算机中关系数据支持两阶段提交协议：

undo日志是记录修改前的数据，用于数据库回滚。

Redo 日志是记录修改后的数据，用于提交事务写入数据文件。

事务管理器向所有参与者发送事务内容，询问是否准备好了，等待参与者的响应，各个参与者事务节点执行事务操作，并将 Undo和Redo 信息记入事务日志中。如果参与者成功执行事务操作，反馈事务管理器YES操作，表示事务可以执行，假如协调者从所有的参与者或得反馈都是Yes响应，那么就会执行事务提交。

假如任何一个参与者向事务管理器反馈了No指令，或者等待超时之后，事务管理器无法接收到所有参与者的反馈响应，那么中断事务，发送回滚请求，事务管理器向所有参与者节点发送 RollBack 请求，参与者接收到 RollBack 请求后，会利用在阶段一记录的Undo信息执行事务的回滚操作，在完成回滚之后释放事务执行期间占用的资源，参与者在完成事务回滚之后，向协调者发送ACK消息，事务管理器在接受到所有参与者反馈的ACK消息之后，完成事务中断。

三阶段提交(3PC)

3PC 主要是为了解决两阶段提交协议的单点故障问题和缩小参与者阻塞范围。是二阶段提交（2PC）的改进版本，引入参与节点的超时机制之外，3PC把2PC的准备阶段分成事务询问（该阶段不会阻塞）和事务预提交,则三个阶段分别为 CanCommit、PreCommit、DoCommit。

CanCommit阶段 协调者(Coordinator)会向参与者(Participant) 发送CanCommit消息，询问是否可以执行操作，参与者收到消息后，表示能够执行，会返回给协调者能够执行的(yes)命令。

如果参与者不能执行，会返回No命令,释放资源，结束事务。

PreCommit 阶段如果协调者收到参与者返回的状态值为YES，那么就证明它们都有能力去执行这个操作，那么协调者就会向所有参与者 发送 PreCommit 消息，协调者收到 PreCommit消息后，回去执行本地事务，如果执行成功会将本地事务保存到 undo和redo 后，再返回给协调者YES指令，如果执行本地事务失败，返回协调者No,只要协调者收到一个执行失败，给所有参与者发送中断事务消息，参与者收到消息后，对事务进行回滚操作。

在这个阶段参与者和协调者都引入了超时机制，如果参与者没有收到，协调者的消息，或者协调者没有收到参与者返回的预执行结果状态，在等待超时之后，事务会中断，避免了事务的阻塞。

协调者向参与者发送PreCommit​，如果参与者执行成功，返回yes。

如果参与者执行失败，只有有一个返回No到协调者，协调者会向参与者发送中断事务的消息，参与者回滚事务。

协调者收到所有参与者返回的状态都是YES，这时协调者会向所有的参与者都发送 DoCommit ，参与者收到 DoCommit 后，会真正的提交事务，当事务提交成功后，返回协调者YES状态，表示我已经完成事务的提交了，协调者收到所有参与者都返回YES状态后，那么就完成了本次事务。

如果某个参与者返回No消息，协调者发送中断事务消息(abort)，给参与者们，参与者回滚事务。

3PC是2PC的升级版，引入了超时机制，解决了单点故障引起的事务阻塞问题，但是3PC依然不能解决事务一致性的问题，因为在DoCommit阶段，如果由于网络或者超时等原则导致参与者收不到协调者发送过来的 中断事务消息(abort) ，过了这个时间后，参与者会提交事务，本来是应该进行回滚，提交事务后，会导致数据不一致的问题出现，2PC虽然在网络故障情况下存在强一致性被破坏的问题，但是故障恢复以后能保证最终一致性，3PC虽然有超时时间，解决了阻塞，提高了可用性，但是牺牲了一致性，如果针对网络波动问题导致数据问题这一点上，2PC是优于3PC的。

Seata

官网：https://seata.io/zh-cn/docs/overview/what-is-seata.html。

Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。

在微服务系统中，一般业务会被拆分成独立的模块，在官方提供的结构图中，我们可以看到当前主要分为三个模块。

在当前架构中，用户挑选心仪的商品下单后，需要三个服务来完成操作，每一个服务的内部都拥有一个独立的本地事务来保证当前服务数据的强一致性，但是三个服务组成的全局事务一致性就没办法进行保证，那么Seata就是来解决这个问题的。

Seata术语

官网地址：https://seata.io/zh-cn/docs/overview/terminology.html。

在了解Seata之前，我们先来了解一下 Seata 几个关键的概念：

Seata 2PC

一阶段： 业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。

二阶段： 提交异步化，非常快速地完成。回滚通过一阶段的回滚日志进行反向补偿。

一阶段本地事务提交前，需要确保先拿到 全局锁 。拿不到全局锁 ，不能提交本地事务。拿全局锁的尝试被限制在一定范围内，超出范围将放弃，并回滚本地事务，释放本地锁。

在数据库本地事务隔离级别读已提交或以上的基础上，Seata（AT 模式）的默认全局隔离级别是 读未提交。

如果应用在特定场景下，必需要求全局的 读已提交 ，目前 Seata 的方式是通过 SELECT FOR UPDATE 语句的代理。

Seata执行流程分析：

每个RM 使用 DataSourceProxy 链接数据路，目的是使用 ConnectionProxy ，使用数据源和数据代理的目的是在第一阶段将 undo和业务数据放在一个本地事务中提交，这样就保存了只要有业务操作就一定会有dudo日志。

在第一阶段中，undo存放了数据修改前后修改的值，是为了事务回滚做好准备，在第一阶段完成就已经将分支事务提交了，也就释放了锁资源。

TM开启全局事务开始，将XID全局事务ID放在事务上下文中，通过feign调用将XID传入下游服务器中，每个分支事务将自己的 Branch ID分支事务ID和XID进行关联。

在第二阶段全局事务提交，TC会通知各个分支参与者提交分支事务，在第一阶段已经提交了分支事务，在这里各参与者只需要删除undo即可，并且可以异步执行。

如果某一个分支事务异常了，第二阶段全局事务回滚操作，TC会通知各个分支参与者回滚分支事务，通过XID和Branch-ID找到对应的回滚日志，通过回滚日志生成的反向SQL执行，完成分支事务回滚到之前的状态。

Seata 下载安装

下载地址：https://github.com/seata/seata/releases。

解压后找到conf目录。

我们在启动seata之前，首先要启动nacos，其实也很简单，只需要下载nacos后启动就行，不知道nacos怎么操作的看这里的介绍nacos基础介绍​，启动好之后，我们再来启动seata，bin目录下seata-server.bat。

如果我们看到8091端口在监听，并且在nacos看到服务注册上去了，就表示我们seata启动成功了。

总结

到这里我们关于分布式事务的和seata的介绍就讲完了，其实关于分布式还有MQ实现可靠消息最终一致性，MQ主要解决了两个功能：本地事务与消息发送的原子性问题。事务参与方接收消息的可靠性。

相关文章