单体时代一个Transactional就能搞定数据一致性。到了微服务订单服务扣库存、账户服务扣余额、积分服务加积分三个数据库、三个服务任何一个环节失败数据就可能错乱。分布式事务之所以难是因为它要在不可靠的网络、可能宕机的节点之间保证多个数据源要么全部成功要么全部失败。好消息是经过多年实践业界已经沉淀出几种成熟方案。下面这4种帮你彻底搞懂。方案一两阶段提交2PC2PC是最经典的强一致方案分准备和提交两个阶段。协调者先问所有参与者“能提交吗”大家各自锁定资源并回复“可以”协调者收到全部“可以”后再通知所有人正式提交。如果任何一个参与者说“不行”协调者就通知全部回滚。优点是数据库层面支持XA协议业务侵入小能保证强一致。缺点也很致命同步阻塞参与者在准备阶段一直占着资源协调者单点故障一旦宕机参与者可能一直等待极端情况下部分节点提交、部分节点未提交数据不一致。所以2PC适合数据库层面、短事务、并发不高的场景互联网高并发业务很少直接用。方案二TCCTry-Confirm-CancelTCC把事务拆成三个业务方法Try做资源检查和预留Confirm做正式提交Cancel做补偿回滚。比如扣库存Try阶段冻结库存Confirm阶段真正扣减Cancel阶段解冻。三个方法都由业务代码实现不依赖数据库的XA。优点是性能好不长期锁资源能实现最终一致。缺点是业务侵入极大每个操作都要写三个方法还要处理幂等、空回滚、悬挂等问题。比如Cancel先于Try到达或者Confirm重复执行都需要额外设计。TCC适合金融、电商等对一致性要求高、且能接受业务改造的核心链路。方案三SagaSaga把一个长事务拆成多个本地事务每个本地事务都有对应的补偿操作。执行时按顺序调用一旦某一步失败就反向依次执行前面已成功步骤的补偿。比如订单流程创建订单→扣库存→扣余额→加积分。如果扣余额失败就补偿扣库存再补偿创建订单。优点是适合长流程、跨多个服务的业务性能比2PC好不需要长期锁资源。缺点是只保证最终一致中间状态对外可见补偿操作需要业务实现且要考虑幂等和重试。Saga适合业务流程长、允许短暂不一致的场景比如旅游预订、供应链。方案四本地消息表 可靠消息最终一致这是互联网最常用的方案。核心思路把“业务操作”和“发消息”放在同一个本地事务里。比如订单服务在本地事务中同时写订单表和消息表然后由定时任务或CDC把消息表里的消息投递给MQ下游服务消费消息执行自己的业务。下游失败就重试直到成功。优点是实现简单不依赖XA性能高能保证最终一致。缺点是只能保证最终一致中间有延迟消息表需要额外存储消费端必须幂等。适合异步、非实时、对一致性要求不是强一致的场景比如发短信、加积分、更新统计。怎么选没有银弹。强一致、短事务、低并发考虑2PC核心链路、能接受业务改造考虑TCC长流程、跨多服务考虑Saga异步、最终一致、高并发考虑本地消息表MQ。实际项目中常常混合使用核心资金用TCC积分、通知用消息表。搞懂这4种方案的原理、优缺点和适用场景分布式事务就不再是玄学。面试时能讲清楚取舍工作中能选对方案你就已经超过了大多数开发者。