分布式事务面试题

分布式事务面试题：搞懂这个，面试官直呼内行！

搞分布式系统，躲不开分布式事务这道坎。面试官十有八九会问，答不好直接扣分！今天咱们就掰开揉碎讲讲常见的分布式事务面试题该怎么答，帮你稳稳过关，顺便分享个超级实用的资源！

👉 2025 Java面试宝典（含分布式专题深度解析）：
点击下载提取码: 9b3g

想象一下：你网购下单，既要扣库存（库存服务），又要创建订单（订单服务），还要扣款（支付服务）。这三个操作在不同服务器、甚至不同机房，必须同时成功或同时失败。这就是分布式事务的核心！

难点在哪？

面试回答要点：

面试鸭返利网

角色：协调者(Coordinator)、参与者(Participants)。
流程：
1. 准备阶段：协调者问所有参与者：“能执行吗？” 参与者锁定资源，回复“YES/NO”。
2. 提交阶段：如果所有回复“YES”，协调者发“提交”命令；否则发“回滚”命令。参与者执行并反馈结果。
优点：强一致性保证（在理想情况下）。
缺点：
- 同步阻塞：参与者锁定资源，等待协调者指令，性能差。
- 协调者单点故障：协调者挂了，整个事务卡死或数据不一致。
- 数据不一致风险：提交阶段网络故障，部分参与者提交成功，部分失败。
面试回答：“2PC像项目经理开项目启动会，先问大家'行不行？'(准备阶段)，都OK就干(提交阶段)，有人不行就散伙(回滚)。缺点是项目经理(协调者)一请假，项目就瘫痪，且大家(参与者)在等指令时啥也干不了。”

核心思想：业务逻辑拆分 Try-Confirm-Cancel 三步。
流程：
1. Try：预留业务资源（如：冻结库存、预扣款）。做检查，保证后续能成功。
2. Confirm：真正执行业务操作（如：扣减库存、实际扣款）。要求幂等。
3. Cancel：Try阶段预留资源的反向操作（如：解冻库存、解冻款）。要求幂等。
优点：
- 避免了同步阻塞，性能较好。
- 最终一致性保证。
缺点：
- 业务侵入性强，每个服务需实现 TCC 接口。
- 开发复杂，要考虑幂等、空回滚、防悬挂。
面试回答：“TCC像网购下单的'预占库存-支付-确认收货'流程。下单( Try )先锁库存，支付( Confirm )真扣钱，取消订单(Cancel)就解锁库存。优点是灵活高效，缺点是每个步骤都要自己写得很小心(业务侵入)。”

核心思想：依赖可靠消息队列，异步确保操作完成。
典型场景：订单创建后，发消息让库存服务扣减库存。
关键保障：
- 消息生产方：本地事务与消息发送必须保证原子性（如：先落订单库+写消息表，再用定时任务扫消息表发MQ）。
- 消息消费方：消息处理要幂等。
优点：解耦彻底，性能高，扩展性好。
缺点：只能保证最终一致性，有延迟。需要处理消息丢失、重复等问题。
面试回答：“这就像你(订单服务)把'扣库存'的纸条(消息)塞进快递柜(消息队列)，通知快递员(库存服务)去取件处理。优点是双方互不干扰(解耦)，快递员可以晚点处理(最终一致)，缺点是纸条可能丢或被塞两张一样的(需幂等保障)。”

核心思想：服务A完成任务后，尽最大努力（多次重试）通知服务B，B收到后执行操作。
适用场景：对一致性要求不高，或者有对账兜底（如：支付结果通知）。
优点：简单、易实现。
缺点：不能保证绝对成功，需额外对账机制。
面试回答：“就像你让朋友帮忙办事，电话打不通你就隔5分钟打一次(重试)，打一天还不通就算了(最终放弃)，后面再找他算账(对账)。简单但不保证100%靠谱。”

CAP和BASE理论是啥？怎么指导方案选择？
- CAP：分布式系统只能三选二（一致性C、可用性A、分区容忍性P）。通常优先保证P，在C和A之间权衡。分布式事务方案多在 CP（如2PC）或 AP（如最终一致）之间选。
- BASE：基本可用(Basically Available)、软状态(Soft state)、最终一致性(Eventually consistent)。它是AP策略的延伸，基于消息、TCC最终态都符合BASE。
幂等性为什么重要？怎么实现？
- 重要：网络重发、服务重试会导致请求重复。不幂等就会扣两次钱、扣两次库存！
- 实现：
  - 数据库唯一键/唯一索引。
  - 版本号/状态机（先查状态，只有特定状态才执行）。
  - Token机制（客户端先申请token，服务端存token状态）。
XA协议是啥？
- 它是一个规范，定义了全局事务管理器（TM）与资源管理器（RM，如数据库）之间的接口，是2PC的一种标准化实现。Java中JTA(Java Transaction API)是XA在Java中的映射。