分布式事务，指的就是在分布式的系统里面完成一些事务，下文介绍了分布式事务的用途是什么？分布式事务产生的情景有哪些等问题。

一、分布式事务的用途是什么？

分布式事务处理 (TP) 系统旨在协助在分布式环境中跨异类的事务识别资源的事务。在分布式 TP 系统的支持下，应用程序可以将不同的活动合并为一个事务性单元，这些活动包括从“消息队列”队列检索消息、将消息存储在 Microsoft SQL Server 数据库中、将所有现有的消息引用从 Oracle Server 数据库中移除，等等。因为分布式事务跨多个数据库资源，故强制 ACID 属性维护所有资源上的数据一致性是很重要的。

二、分布式事务产生的情景

1.跨JVM进程产生分布式事务
典型的场景就是微服务架构：微服务之间通过远程调用完成事务操作。比如：订单微服务和库存微服务，下单的同时订单微服务请求库存微服务减少库存。

2.跨数据库实例产生分布式事务
单体系统访问多个数据库实例当单体系统需要访问多个数据库（实例）时就会产生分布式事务。比如：用户信息和订单信息分别在两个MySQL实例存储，用户管理系统删除用户信息，需要分别删除用户信息及用户的订单信息，由于数据分布在不同的数据实例，需要通过不同的数据库链接去操作数据，此时产生分布式事务。

3.多服务访问同一个数据库实例
订单微服务和库存微服务即使访问同一个数据库也会产生分布式事务，原因就是跨JVM进程，两个微服务持有了不同的数据库链接进行数据库操作，此时产生分布式事务。

分布式事务的解决方案

一、两阶段提交（2PC）

两阶段提交（Two-phase Commit，2PC），通过引入**协调者（Coordinator）**来协调参与者的行为，并最终决定这些参与者是否要真正执行事务。

准备阶段

协调者询问参与者事务是否执行成功，参与者发回事务执行结果。

提交阶段

如果事务在每个参与者上都执行成功，事务协调者发送通知让参与者提交事务；否则，协调者发送通知让参与者回滚事务。

需要注意的是，在准备阶段，参与者执行了事务，但是还未提交。只有在提交阶段接收到协调者发来的通知后，才进行提交或者回滚。

二、补偿事务（TCC）

TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。它分为三个阶段：
1)、Try 阶段主要是对业务系统做检测及资源预留.

2)、Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。

3)、Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。

优点： 跟2PC比起来，实现以及流程相对简单了一些，但数据的一致性比2PC也要差一些

缺点： 缺点还是比较明显的，在2,3步中都有可能失败。TCC属于应用层的一种补偿方式，所以需要程序员在实现的时候多写很多补偿的代码，在一些场景中，一些业务流程可能用TCC不太好定义及处理。

相应的还有很多模式：如3PC、AT 模式、Saga 模式、XA 模式
详情可见：
https://blog.csdn.net/qq_45738250/article/details/126214367
https://blog.csdn.net/zengqingfa123/article/details/127465218

通常都是使用seata事务架构来处理分布式事务，其提供了AT、TCC、Saga、XA(在2PC之上使用的)四种事务模式解决方案,我学习是在B站尚硅谷的springcloud最后几集进行学习的，有兴趣可以去学习一下，seata也是目前比较常用的用来处理分布式事务的