微服务架构下一次下单要扣库存、减余额、发优惠券三个服务三个数据库任何一步失败都可能让数据对不上。分布式事务就是解决这个问题的。但方案五花八门选错了比不做还糟。今天用最直白的话讲透6种主流方案。1. 2PC/3PC数据库层的强一致方案两阶段提交把事务分成准备和提交两步协调者统一指挥。准备阶段所有参与者锁定资源提交阶段统一执行。3PC在中间加了预提交和超时机制缓解阻塞。优点是强一致数据库原生支持XA。缺点也致命同步阻塞协调者单点准备阶段后协调者宕机可能导致数据不一致。适合传统金融场景并发不高、对强一致要求极高但微服务下很少用。2. TCC业务层的补偿事务Try阶段预留资源Confirm确认执行Cancel取消释放。比如扣库存Try先冻结Confirm真正扣减Cancel解冻。TCC不依赖数据库锁性能好能跨服务。代价是业务侵入极大每个操作要写三个接口还要处理空回滚、幂等、悬挂。适合高并发短事务比如电商大促的下单扣库存。3. 本地消息表最朴素的最终一致在本地事务里同时写业务数据和一条消息记录然后异步把消息投递出去下游消费成功后回执。如果投递失败定时任务扫表重发。实现简单不依赖MQ高级特性但消息表和业务库耦合需要额外补偿逻辑。适合对一致性要求不苛刻、能接受最终一致的场景。4. 事务消息MQ加持的可靠投递以RocketMQ为代表先发半消息执行本地事务再根据结果提交或回滚。半消息对消费者不可见只有提交后才可消费。优点是解耦消息可靠最终一致。缺点是要换MQ实现复杂消息可能重复消费端必须幂等。适合已有RocketMQ、需要异步解耦的业务。5. Saga长流程的逆向补偿把长事务拆成多个本地事务每个都有对应的补偿操作。成功就继续失败就逆向执行补偿。比如旅行预订先订机票再订酒店酒店失败就取消机票。Saga没有锁高可用适合长流程。但没有隔离性中间状态可能被看到补偿逻辑要仔细设计。适合业务流程长、参与方多的场景。6. 最大努力通知弱一致的兜底发起方尽力通知接收方主动查询不保证一定成功。比如支付回调通知失败就定时重试再不行就让对方来查。实现最简单但可靠性最低必须配对账兜底。适合对结果不敏感、能接受最终对账的场景。怎么选强一致选2PC/TCC最终一致选本地消息表/事务消息/Saga弱一致选最大努力通知。还要看并发量、业务侵入接受度、技术栈。没有银弹只有取舍。理解每种方案的边界比盲目套用更重要。