引言分布式事务是Java面试中高级岗位的必考题。单体时代Transactional一个注解就能搞定微服务拆分后一个业务操作横跨多个服务、多个数据库数据一致性就成了大难题。面试官问分布式事务其实是在考察你对一致性模型、补偿机制和落地成本的权衡能力。下面这4种方案一次讲清。一、2PC两阶段提交强一致但笨重2PCTwo-Phase Commit把事务分为准备和提交两个阶段。准备阶段协调者询问所有参与者能否提交参与者执行事务但不提交锁定资源并返回结果。提交阶段如果所有参与者都同意协调者通知提交否则通知回滚。优点强一致性实现相对简单数据库层面原生支持XA协议。缺点同步阻塞参与者在准备阶段一直锁资源性能差协调者单点故障如果协调者在提交阶段宕机参与者会一直阻塞数据不一致风险部分参与者提交后协调者才宕机会导致数据错乱。适用场景传统银行、金融等对强一致要求极高、并发不高的内部系统。Java中可用Atomikos、Narayana实现。面试回答要点2PC是强一致方案但性能和可用性差互联网高并发场景基本不用。二、TCCTry-Confirm-Cancel业务层补偿TCCTry-Confirm-Cancel把每个操作拆成三个方法Try阶段做业务检查和资源预留Confirm阶段确认执行使用Try预留的资源Cancel阶段取消执行释放预留资源。优点不依赖数据库事务性能好锁粒度小只锁业务资源可跨服务、跨数据库。缺点业务侵入性强每个接口都要写三个方法需要处理空回滚、幂等、悬挂等问题Confirm和Cancel必须幂等。适用场景电商、支付等高并发场景如订单扣库存、账户扣款。Java中可用Seata的TCC模式、Hmily。面试回答要点TCC是业务层面的两阶段核心是补偿难点是幂等和防悬挂。三、可靠消息最终一致性MQ本地消息表核心思路业务操作和发送消息在同一个本地事务中完成。比如订单服务创建订单后把消息写入本地消息表再由定时任务或MQ事务消息投递。下游服务消费消息执行自己的业务失败则重试直到成功。优点异步解耦吞吐量高最终一致性适合长流程业务。缺点一致性延迟中间状态可能被看到需要保证消息不丢、不重、有序本地消息表增加了数据库压力。适用场景订单成功后通知积分、优惠券、物流等下游系统。RocketMQ事务消息是典型实现。面试回答要点最终一致性不是强一致但换来了高可用和高性能互联网场景首选。四、最大努力通知不保证成功只保证尽力最大努力通知是最弱的一致性方案。发起方执行完业务后通过MQ或HTTP通知接收方接收方处理失败后发起方按策略重试重试到一定次数后不再保证。接收方也可以主动查询对账。优点实现简单对发起方侵入小。缺点不保证最终一致只保证“尽力”需要人工兜底或对账补偿。适用场景支付结果通知、外部系统回调等对一致性要求不高的场景。面试回答要点最大努力通知适合可容忍不一致的业务通常配合对账系统使用。总结分布式事务没有银弹。2PC强一致但性能差TCC性能好但业务侵入大可靠消息最终一致性是互联网主流最大努力通知则用于弱一致场景。面试时先讲清每种方案的原理和优缺点再结合业务场景给出选型建议最后提一句“实际项目中往往多种方案混合使用”就能让面试官看到你的架构思维。
