分布式事务

分布式事务：面试高频难题，一文帮你搞定！

最近面了几家大厂，发现「分布式事务」真是妥妥的高频考点啊！不管你是面初中高级，基本都会被问到。今天咱们就来聊聊这个让很多程序员头疼的玩意儿，帮你面试时自信应对。对了，分享个超级实用的资源：2025年Java面试宝典，包含各种分布式系统核心知识：百度网盘链接 提取码：9b3g （建议提前保存）！

为什么分布式事务这么难搞？

想象一下：你的应用拆成了用户服务、订单服务、库存服务，一个下单操作要同时扣减库存、生成订单、增加积分。这三个操作在不同服务、不同数据库甚至不同机器上，怎么保证它们要么全成功，要么全失败？这就是分布式事务的核心难题 —— 在分布式环境下实现ACID中的原子性（Atomicity）。

传统数据库的本地事务（比如MySQL的InnoDB）通过锁和日志回滚就能搞定，但一涉及到跨服务调用，网络抖动、服务宕机分分钟教你做人。所以，我们需要专门的分布式事务解决方案。

主流分布式事务解决方案盘点

方案一：两阶段提交 (2PC)

这是最经典的分布式事务协议，像个靠谱的协调者：

1. 准备阶段 (Prepare Phase)：

   • 分布式事务协调者(TM)问所有参与者(RM)："哥们，我要执行xxx操作，你这边能commit不？"
   • 每个参与者检查自己状态（比如资源够不够、能不能执行），然后锁住资源，回复"Ready to commit" (Yes) 或 "Abort" (No)。

2. 提交阶段 (Commit Phase)：

   • 如果所有参与者都回复Yes，协调者发"Commit"指令，大家真正提交事务，释放锁。
   • 如果有任何一个回复No（或超时），协调者发"Rollback"，大家回滚操作，释放锁。

面试踩坑点：

• 同步阻塞：参与者资源在准备阶段就被锁住，其他操作只能干等着，性能是大问题。
• 协调者单点故障：协调者要是跪在发Commit之前，参与者就一直傻等（阻塞）；跪在发Commit之后，部分参与者可能没收到Commit导致数据不一致。
• 数据不一致风险：即使很少见，如果网络分区导致某个参与者没收到Commit指令，也会导致不一致。 总的来说，2PC追求强一致，但性能差、可用性低，适合一致性要求极高、参与者少的场景。

方案二：TCC (Try-Confirm-Cancel)

TCC本质上是一种补偿型分布式事务方案，把一个大操作拆成三个小操作：

1. Try：尝试阶段。干点准备工作，比如检查+冻结资源（冻结库存、冻结优惠券额度），让资源进入一个"中间态"。这个阶段不会最终提交。
2. Confirm：确认阶段。如果所有Try都成功了，就执行真正的业务操作（扣减冻结的库存、使用优惠券）。要求Confirm操作必须成功。
3. Cancel：取消阶段。如果任何一个Try失败（或者超时、收到Cancel指令），就执行补偿操作，把Try阶段冻结的东西释放掉（解冻库存、返还优惠券额度）。

面试亮点：

• 强调业务侵入性强：每个服务都要实现这三个接口。
• 强调幂等性：Confirm和Cancel操作可能被重复调用，所以必须保证执行多次效果相同。
• 强调空回滚：处理Try还没执行就收到Cancel的情况（Try记录不存在时Cancel也要能执行）。
• 最终一致性：通过不断重试保证最终数据一致，中间可能有短暂不一致。

TCC性能通常比2PC好（无全局锁），但开发复杂（得写Confirm/Cancel），适合金融、电商等对一致性要求高但能容忍短暂不一致的场景。

方案三：基于消息队列的最终一致性 (Saga变种/本地消息表)

这是互联网公司用得最多的方案之一，实现最终一致性：

1. 主服务执行本地事务（比如创建订单记录）。
2. 在同一个本地事务中，记录一条要发送的"消息"（比如库存扣减消息）到一个专门的本地表（本地消息表）。
3. 后台有一个定时任务轮询这个表，把消息发到MQ（如RocketMQ、Kafka）。
4. 下游服务（库存服务）消费MQ消息，执行自己的操作（扣减库存）。如果失败，MQ的重试机制能保证最终成功（可能需要人工介入处理实在搞不定的）。
5. 下游服务处理成功后，可能再发一条消息回来更新主服务状态（可选）。

面试必答点：

• 核心优势：解耦，异步，性能好，可用性高。
• 核心挑战：保证消息一定发出去（本地事务保证消息入库）、消息可能重复（消费者端必须幂等）。
• 最终一致性：需要时间窗口来达成一致。

适合跨系统集成、链路长、对强一致性要求不高的场景（如发通知、更新缓存、记录日志）。本地消息表是实现可靠消息投递的关键手段。

方案四：Saga

可以把Saga理解成一个长事务，由一系列本地事务组成。每个本地事务执行后，都发布一个事件。如果某个本地事务失败，Saga会执行一系列补偿操作（按反向顺序）来撤销之前成功的操作。

和TCC区别在于：TCC每个操作要业务方显式写补偿逻辑；Saga的补偿逻辑更偏向业务层面的事务回滚（比如订单创建成功了要取消，就调用订单服务的取消接口），而不是像TCC那样操作DB记录。

面试时怎么选？记住这几点！

1. 先问一致性要求：是要强一致（2PC），还是最终一致可以接受（TCC, MQ, Saga）？
2. 再看性能瓶颈：强一致方案通常性能差。
3. 考虑开发成本：2PC相对成熟但集成难；TCC开发成本高；MQ方案解耦性好开发成本适中。
4. 提防故障场景：面试官最爱问“如果协调者挂了/网络断了/重复调用怎么办？”（2PC单点、TCC幂等和空回滚、MQ消息幂等）
5. 结合项目聊：最好能说说你项目中用了哪种分布式事务方案，为什么选它，遇到了什么坑。

分布式事务没有银弹，理解原理才能以不变应万变！如果你正在准备面试，需要刷题资源，悄悄告诉你：通过 面试鸭返利网 找我购买面试鸭会员，能返利25元！省一点是一点嘛。

---

希望这篇关于分布式事务的解析能帮你在面试中游刃有余！记住，把网盘里的面试宝典好好利用起来！