一口气说出了七种分布式事务的解决方案，你知道哪几种？

分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器**「分别位于不同的分布式系统的不同节点之上」**。

一个大的操作由N多的小的操作共同完成。而这些小的操作又分布在不同的服务上。针对于这些操作，「要么全部成功执行，要么全部不执行」。

为什么会有分布式事务？

===========

举个例子：

转账是最经典的分布式事务场景，假设用户 A 使用银行 app 发起一笔跨行转账给用户 B，银行系统首先扣掉用户 A 的钱，然后增加用户 B 账户中的余额。

如果其中某个步骤失败，此时就有可能会出现 2 种**「异常」**情况：

• 1.用户 A 的账户扣款成功，用户 B 账户余额增加失败

• 2.用户 A 账户扣款失败，用户 B 账户余额增加成功。

对于银行系统来说，以上 2 种情况都是**「不允许发生」**，此时就需要事务来保证转账操作的成功。

在**「单体应用」中，我们只需要贴上@Transactional注解就可以开启事务来保证整个操作的「原子性」**。

但是看似以上简单的操作，在实际的应用架构中，不可能是单体的服务，我们会把这一系列操作交给**「N个服务」去完成，也就是拆分成为「分布式微服务架构」**。

比如下订单服务，扣库存服务等等，必须要**「保证不同服务状态结果的一致性」**，于是就出现了分布式事务。

分布式理论

=====

CAP定理

---

在一个分布式系统中，以下三点特性无法同时满足，「鱼与熊掌不可兼得」

一致性（C）：

在分布式系统中的所有数据备份，「在同一时刻是否拥有同样的值」。（等同于所有节点访问同一份最新的数据副本）

可用性（A）：

在集群中一部分节点**「故障」后，集群整体「是否还能响应」**客户端的读写请求。（对数据更新具备高可用性）

分区容错性（P）：

即使出现**「单个组件无法可用,操作依然可以完成」**。

具体地讲在分布式系统中，在任何数据库设计中，一个Web应用**「至多只能同时支持上面的两个属性」**。显然，任何横向扩展策略都要依赖于数据分区。因此，设计人员必须在一致性与可用性之间做出选择。

BASE理论

---

在分布式系统中，我们往往追求的是可用性，它的重要程序比一致性要高，那么如何实现高可用性呢？

前人已经给我们提出来了另外一个理论，就是BASE理论，它是用来对CAP定理进行进一步扩充的。BASE理论指的是：

• 「Basically Available（基本可用）」

• 「Soft state（软状态）」

• 「Eventually consistent（最终一致性）」

BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

分布式事务解决方案

=========

两阶段提交（2PC）

---

熟悉mysql的同学对两阶段提交应该颇为熟悉，mysql的事务就是通过**「日志系统」**来完成两阶段提交的。

两阶段协议可以用于单机集中式系统，由事务管理器协调多个资源管理器；也可以用于分布式系统，「由一个全局的事务管理器协调各个子系统的局部事务管理器完成两阶段提交」。

这个协议有**「两个角色」**，

A节点是事务的协调者，B和C是事务的参与者。

事务的提交分成两个阶段

第一个阶段是**「投票阶段」**

• 1.协调者首先将命令**「写入日志」**

• 2. **「发一个prepare命令」**给B和C节点这两个参与者

• 3.B和C收到消息后，根据自己的实际情况，「判断自己的实际情况是否可以提交」

• 4.将处理结果**「记录到日志」**系统

• 5.将结果**「返回」**给协调者

第二个阶段是**「决定阶段」**

当A节点收到B和C参与者所有的确认消息后

• 「判断」所有协调者「是否都可以提交」

• 如果可以则**「写入日志」**并且发起commit命令

• 有一个不可以则**「写入日志」**并且发起abort命令

• 参与者收到协调者发起的命令，「执行命令」

• 将执行命令及结果**「写入日志」**

• **「返回结果」**给协调者

可能会存在哪些问题？

• 「单点故障」：一旦事务管理器出现故障，整个系统不可用

• 「数据不一致」：在阶段二，如果事务管理器只发送了部分 commit 消息，此时网络发生异常，那么只有部分参与者接收到 commit 消息，也就是说只有部分参与者提交了事务，使得系统数据不一致。

• 「响应时间较长」：整个消息链路是串行的，要等待响应结果，不适合高并发的场景

• 「不确定性」：当事务管理器发送 commit 之后，并且此时只有一个参与者收到了 commit，那么当该参与者与事务管理器同时宕机之后，重新选举的事务管理器无法确定该条消息是否提交成功。

三阶段提交（3PC）

---

三阶段提交又称3PC，相对于2PC来说增加了CanCommit阶段和超时机制。如果段时间内没有收到协调者的commit请求，那么就会自动进行commit，解决了2PC单点故障的问题。

但是性能问题和不一致问题仍然没有根本解决。下面我们还是一起看下三阶段流程的是什么样的？

• 第一阶段：**「CanCommit阶段」**这个阶段所做的事很简单，就是协调者询问事务参与者，你是否有能力完成此次事务。

• 如果都返回yes，则进入第二阶段

• 有一个返回no或等待响应超时，则中断事务，并向所有参与者发送abort请求

• 第二阶段：**「PreCommit阶段」**此时协调者会向所有的参与者发送PreCommit请求，参与者收到后开始执行事务操作，并将Undo和Redo信息记录到事务日志中。参与者执行完事务操作后（此时属于未提交事务的状态），就会向协调者反馈“Ack”表示我已经准备好提交了，并等待协调者的下一步指令。

• 第三阶段：**「DoCommit阶段」**在阶段二中如果所有的参与者节点都可以进行PreCommit提交，那么协调者就会从“预提交状态”转变为“提交状态”。然后向所有的参与者节点发送"doCommit"请求，参与者节点在收到提交请求后就会各自执行事务提交操作，并向协调者节点反馈“Ack”消息，协调者收到所有参与者的Ack消息后完成事务。相反，如果有一个参与者节点未完成PreCommit的反馈或者反馈超时，那么协调者都会向所有的参与者节点发送abort请求，从而中断事务。

补偿事务（TCC）

---

TCC其实就是采用的补偿机制，其核心思想是：「针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作」。它分为三个阶段：

「Try,Confirm,Cancel」

• Try阶段主要是对**「业务系统做检测及资源预留」**，其主要分为两个阶段

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

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

比如下一个订单减一个库存：

执行流程：

• Try阶段：订单系统将当前订单状态设置为支付中，库存系统校验当前剩余库存数量是否大于1，然后将可用库存数量设置为库存剩余数量-1，

• 如果Try阶段**「执行成功」**，执行Confirm阶段，将订单状态修改为支付成功，库存剩余数量修改为可用库存数量

• 如果Try阶段**「执行失败」**，执行Cancel阶段，将订单状态修改为支付失败，可用库存数量修改为库存剩余数量

TCC 事务机制相比于上面介绍的2PC，解决了其几个缺点：

• 1.「解决了协调者单点」，由主业务方发起并完成这个业务活动。业务活动管理器也变成多点，引入集群。

• 2.「同步阻塞」：引入超时，超时后进行补偿，并且不会锁定整个资源，将资源转换为业务逻辑形式，粒度变小。

• 3.「数据一致性」，有了补偿机制之后，由业务活动管理器控制一致性

总之，TCC 就是通过代码人为实现了两阶段提交，不同的业务场景所写的代码都不一样，并且很大程度的**「增加」了业务代码的「复杂度」**，因此，这种模式并不能很好地被复用。

本地消息表

---

执行流程：

• 消息生产方，需要额外建一个消息表，并**「记录消息发送状态」**。消息表和业务数据要在一个事务里提交，也就是说他们要在一个数据库里面。然后消息会经过MQ发送到消息的消费方。

《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》

【docs.qq.com/doc/DSmxTbFJ1cmN1R2dB】 完整内容开源分享

• 如果消息发送失败，会进行重试发送。

• 消息消费方，需要**「处理」这个「消息」**，并完成自己的业务逻辑。

• 如果是**「业务上面的失败」，可以给生产方「发送一个业务补偿消息」**，通知生产方进行回滚等操作。