跨库跨服务时本地事务不够用了。本文梳理分布式事务方案谱系及边界，强调”先减少分布式事务，再选对一致性级别”的工程思路。

要解决什么问题

微服务各用独立数据库，下单涉及订单库、库存库、支付库，任一环节失败需整体回滚或补偿。单机 ACID 无法跨进程；分库分表后即使同一业务也可能跨物理库。若强行 2PC，锁持有时间长、吞吐下降，且协调者单点风险高。

核心原理

2PC/XA 强一致但阻塞；Seata AT 基于 undo log 自动回滚，对业务侵入低；TCC 业务层 Try/Confirm/Cancel，灵活但编码和幂等成本高；Saga 长流程正向链+补偿链；本地消息表与 RocketMQ 事务消息通过”先落库再异步确认”实现最终一致。BASE 是大多数互联网业务的真实选择。

方案权衡

强一致适合短事务、高价值金融场景；最终一致适合订单、积分、通知等可补偿场景。没有银弹——选方案看一致性要求、开发成本、运维成熟度。能合并服务或单库事务就尽量合并，是成本最低的”分布式事务解决方案”。

落地要点

Outbox 模式保证消息与本地写同事务落库；TCC Confirm/Cancel 必须幂等；Saga 配状态机可视化与对账任务；监控悬挂、空回滚、幂等失效。Seata 注意 undo log 清理与全局锁范围。压测 AT 模式下的全局锁竞争。业务上定义清晰的状态机，哪些状态允许中间态对用户可见。

常见误区

误区：所有场景都要强一致；TCC 不写 Cancel 幂等；忽视消息回查；把分布式锁当事务。ACID 的 C 在 DDIA 语境中是应用层属性，不要把它当成数据库单独保证的东西来背概念。