面试官问了我分布式事务，我感觉他有想给我40k的冲动，java面试官常问的问题答案

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注Java）

正文

接下来我们看看分布式事务有哪几种实现方案。

分布式事务实现方案

1. 基于数据库资源层面
2. 2PC 两阶段提交协议
3. 3PC 三阶段提交协议
4. 基于业务层面
5. TCC

基于数据库资源层面实现方案，由于存在多个事务，我们需要存在一个角色管理各个事务的状态。我们将这个角色称为协调者，事务参与者称为参与者。参与者与协调者一般会基于某种特定协议，目前比较有名的为 XA 接口协议。基于协调者与参与者的思想设定，分别提出了 2PC 与 3PC 实现XA 分布式事务。

2PC 两阶段提交协议

如名字所知，这个过程主要分为两步。

第一阶段，协调者(事务管理器)将涉及到事务的进行预提交，这个时候数据库资源开始被锁定。参与者将 undo 与 redo 写入事务日志。第二阶段，参与者（资源管理器）行提交事务，或者利用 undo 日志回滚事务，释放资源。

整个过程如下图。

分布式事务提交成功场景：

分布式事务回滚场景：

该方案的优点为:实现比较简单，主流数据库都支持，强一致性。MySQL 5.5 以后基于 XA 协议实现.

相应该方案也存在缺点:

1. 协调者的单点问题。若协调者在提交阶段宕机，参与者一直在等待,就一直锁定资源，一直阻塞。虽然可以重新选举协调者，但是无法解决该问题。
2. 同步阻塞时间过长，整个执行过程事务是阻塞的，直到提交完成，释放资源，若在提交过程/回滚过程，因为网络延时，参与者一直未收到指令，则参与者一直被阻塞。
3. 数据不一致。第二阶段，协调者发出第一个提交信号后后宕机，则第一个参与者提交事务，第二个参与者因为未收到协调者信号，无法进行事务提交。

于是针对 2PC 存在的缺点，提出改进方案，3PC。

3PC 三阶段提交协议

三阶段提交，在两阶段提交的基础下，改进两阶段。三阶段步骤如下。

1. CanCommit,协调者询问参与者是否可以进行事务提交。
2. PreCommit ,若所有参与者可以进行事务提交，协调者下达 PreCommit 命令，参与者锁定资源，并等待最终命令。
3. 所有参与者返回确认信息，协调者向各个事务下发事务执行通知，锁定资源，并将执行情况返回。
4. 部分参与者返回否认信息或协调者等待超时。这种情况，协调者认为事务无法正常执行，下发中断指令，各个参与者退出预备状态
5. Do Commit，若第二阶段全部回应 ack，则下达 Do Commit ，进行事务最终提交，否则下达中断事务命令，所有参与者进行事务回滚。
6. 所有参与者正常执行执行事务，协调者下发最终提交指令，释放锁定资源。
7. 部分参与者执行事务失败，协调者等待超时，协调者下发回滚指令，释放锁定资源。

具体见下图。

三阶段提交对比两阶段，引入超时机制减少事务阻塞，解决单点故障。在第三阶段，一旦参与者无法接受到协调者信号时，等待超时之后，参与者默认执行 commit，释放资源。

三阶段仍然不能解决数据一致性问题。若协调者发出回滚命令，但是由于网络问题，参与者在等待时间内都无法接收到，这时参与者默认提交事务，而其他事务进行了回滚，造成事务不一致。

TCC

TCC 事务

为了解决在事务运行过程中大颗粒度资源锁定的问题，业界提出一种新的事务模型，它是基于业务层面的事务定义。锁粒度完全由业务自己控制。它本质是一种补偿的思路。它把事务运行过程分成 Try、Confirm / Cancel 两个阶段。在每个阶段的逻辑由业务代码控制。这样就事务的锁粒度可以完全自由控制。业务可以在牺牲隔离性的情况下，获取更高的性能。

TCC 分别为 Trying，Confirm，Cancel 三个单词缩写。不同于 2PC 与 3PC 基于数据库层面，TCC 基于应用层面。TCC 三个动作分别为：

Trying：

• 完成所有业务检查(一致性)
• 预留必须业务资源(准隔离性)

Confirm:

• 真正执行业务
• Confirm操作要满足幂等性

Cancel:

• 释放Try阶段预留的业务资源
• Cancel操作要满足幂等性

上面说法，一听起来有点生涩难懂，没关系我们使用实际案例解释。

下面我们模拟商城一次支付过程。用户下单使用组合支付，即余额加红包支付。一次正常流程为：

1. 创建订单
2. 下单
3. 调用余额系统，扣减余额
4. 调用红包系统，扣减红包余额
5. 修改订单状态为已支付
6. 完后支付。

实际过程如下图。

但是这么一个支付过程调用多个子服务，我们不能保证所有服务都能成功，比如我们在调用红包系统扣减红包系统失败。这个时候我们就碰到尴尬的场景，由于红包服务失败，导致方法异常退出，这个时候订单状态为初始状态，但是用户余额已经扣减。这对用户体验非常不友好。所以这次支付过程，我们必须存在机制将这次过程当成一次整体的行为，必须保证这其中服务调用，要么都成功，要么都失败，成为一个整体的事务。

这时我们可以引入 TCC 事务，将整个下单过程作为一个整体。引入后，由于余额系统扣减是失败，这个时候我们回滚订单系统与红包系统。整个过程如下图。

由于余额系统的失败，我们需要撤销这次过程中所有更改，所以我们向订单系统发送撤销通知，向红包系统发出撤销通知。

因此系统引入 TCC 事务后，我们需要改造我们的调用过程。

系统如何引入 TCC 事务

根据 TCC 事务三步，这个时候我们必须将各个服务改造成 Try Confirm Cancle 三步、

TCC TRY:

根据上面的业务，订单系统增加 try 方法将订单状态修改成 PAYING。余额系统增加一个 try 方法，先检查用于余额是否充足，然后先将余额扣减，然后将扣减的余额增加到冻结金额。红包系统同余额系统。从改造过程可以看出，TCC try 方法需检查各业务资源，且这过程需要引入中间状态。我们根据下图来看整个过程。

TCC Confirm:

TCC 第一步 TRY 如果所有子服务调用都成功，这个时候我们就需要确认各服务。各个服务增加 confirm 方法。如余额系统 confirm 方法用来将冻结金额置为0，红包系统如上。订单系统将订单状态修改为 SUCCESS。confirm 方法需要注意实现幂等。如订单系统更新前，一定要先判断该笔订单状态处于 PAYING，才能更新订单。整个过程如下图。

讲到这里，必须用到 TCC 事务框架推动各服务。TCC 事务管理器感知到 TRY 方法结束后，自动调用各服务提供的 confirm 方法，将各服务状态修改为终态。

TCC Cancle：

如若 TCC Try 过程中，冻结红包方法失败，这时我们就需要将之前修改都撤销，修改成其初始状态。cancle 方法也需要实现幂等如 confirm 方法 如下图：

看到这，我们我们可以看出 TCC Try 成功，confirm 必定要成功，try 失败，cancle 必定要成功。因为 confirm 是系统更新为终态的关键。但是现实这么无情，生产系统 confirm 或 cancle 肯定会有几率失败，这个时候就需要 TCC 框架记录调用 confirm 结果。如果 confirm 调用失败，TCC 框架需要记录下来，然后间隔一定时间再次去调用。

读者福利

更多笔记分享

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
添加V获取：vip1024b （备注Java）**
[外链图片转存中…(img-PtXbPHaz-1713558843125)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！