2026年的Java面试分布式事务几乎是必考项。面试官会从“你们项目怎么处理分布式事务的”切入然后一路追问2PC的原理是什么有什么缺陷TCC和2PC有什么区别为什么你们不用TCC最终一致性怎么保证这一套“连环炮”打下来能答透的人不超过30%。分布式事务的核心问题其实很简单一个业务操作跨越多个数据库或服务节点如何保证原子性——要么全成功要么全回滚。下面我把面试中最常被问到的三个方案拆开讲清楚。第一炮2PC两阶段提交——强一致的“老大哥”但互联网项目很少用2PC是分布式事务最经典的解决方案核心思路是通过一个中心化协调者统一管理所有参与者的事务提交或回滚。整个过程分两个阶段准备阶段协调者问所有参与者“能不能提交”参与者执行预操作但不提交锁定资源返回YES或NO提交阶段全票通过就发Commit有一个NO就全体回滚优点很直接强一致性严格遵循ACID数据库原生支持MySQL XA协议业务代码零侵入。但缺陷同样致命同步阻塞准备阶段所有参与者都锁着资源。有开发者反馈高峰期锁持有时间达500ms业务操作本身才10ms剩下全是等锁。单点故障协调者挂了所有参与者卡在准备阶段无法释放资源。脑裂风险网络分区时协调者可能给部分节点发提交、部分发回滚数据就乱了。面试官追问“既然2PC问题这么多你们项目用吗”——实话实说互联网高并发场景基本不用。2PC只适合低并发、短事务、对强一致性要求极高的场景比如银行核心系统的内部账务调整。第二炮TCCTry-Confirm-Cancel——高性能的补偿方案但开发成本极高TCC是一种业务层侵入式的柔性分布式事务方案将事务拆分为三个阶段Try预留资源。比如转账场景先把A账户100块冻结不是直接扣掉Confirm确认提交。所有Try成功后执行实际操作——把冻结的100块从A转到BCancel取消回滚。任一Try失败释放预留资源——把冻结的100块解冻优势相比2PCTCC在Try阶段就完成了资源预留无长时锁阻塞性能优越。适合高并发、对一致性要求高的核心业务如电商下单、秒杀。但坑也很多空回滚Cancel执行了但Try根本没执行过。比如Try请求超时了调用方以为失败就调Cancel但Try其实成功了——钱已经冻结了。Cancel执行的时候把没冻结的钱给“解冻”了账对不上。幂等问题网络重试可能导致Confirm或Cancel被重复调用必须用事务ID做幂等控制。开发成本极高每个业务接口都要实现Try/Confirm/Cancel三个方法代码量翻三倍。面试官常问“TCC和2PC的本质区别是什么”——2PC在数据库层面TCC在应用层面。2PC锁的是数据库资源TCC锁的是业务资源比如冻结库存粒度更细、性能更好但业务代码侵入性极强。第三炮最终一致性——互联网项目的“最优解”面试官最后通常会问“那你们项目最终选了什么”——大部分互联网项目最终一致性方案才是答案。最终一致性基于BASE理论基本可用、软状态、最终一致性允许短暂的数据不一致但最终所有节点会达成一致。下单后库存扣减和订单创建中间差几毫秒用户根本感知不到。主要有两种实现方式本地消息表 消息队列事务发起方在一个本地事务里同时写业务数据和消息表然后通过定时任务轮询投递消息下游消费后更新状态。优点是实现简单、不依赖特定中间件缺点是定时轮询有延迟、消息表耦合业务。事务消息如RocketMQ先发“半消息”对下游不可见执行本地事务成功则提交半消息让下游可见失败则回滚。RocketMQ还有回查机制本地事务提交成功但确认消息丢了会主动反查上游补偿。优点是吞吐高、解耦好缺点是强依赖特定消息中间件。面试官终极追问怎么选面试官最后一定会问“那这三种方案你们怎么选”——记住一句话分布式事务没有银弹能最终一致就别强一致。决策逻辑很清晰强一致性优先 低并发→ 2PC金融核心转账、清算强一致性优先 高并发→ TCC支付、账户扣减但要接受高开发成本可接受最终一致性 高吞吐→ 本地消息表或事务消息电商下单、积分同步长事务多步骤、耗时久→ Saga模式物流、供应链最后再补一句加分的话“如果不想写太多补偿代码可以考虑Seata的AT模式无侵入自动回滚但要接受全局锁带来的性能损耗适合低并发场景”。分布式事务没有完美方案从业务容忍度出发做选型才是落地的关键。这一套答下来面试官基本就给你打上“真懂”的标签了。