已完成分析共参考 6 篇资料常见的分布式事务方案可以从“刚性事务追求强一致性”和“柔性事务追求最终一致性”两个维度来理解。在微服务和多数据库场景下需要根据业务对一致性、性能、侵入性的要求做取舍。1. 刚性事务强一致性基于 ACID2PC两阶段提交原理协调者统一调度第一阶段询问所有参与者是否准备好参与者锁定资源但不提交第二阶段根据投票结果统一提交或回滚。优缺点强一致、对业务侵入小但同步阻塞、锁资源时间长、协调者单点故障风险性能较差。适用场景低并发、对数据强一致性要求极高的场景如银行核心转账、跨库结算。3PC三阶段提交原理在 2PC 基础上增加CanCommit预提交阶段和超时机制分 CanCommit / PreCommit / DoCommit 三阶段。优缺点降低了协调者宕机导致的阻塞风险但协议更复杂网络分区下仍可能不一致工程落地较少。XA 模式本质是数据库层面的 2PC 实现如 MySQL XASeata 也提供了 XA 模式封装属于强一致方案。2. 柔性事务最终一致性基于 BASETCCTry-Confirm-Cancel原理业务层面实现三接口——Try 预留资源、Confirm 确认执行、Cancel 释放/补偿。优缺点性能好、无数据库长锁、可对接异构资源但业务侵入性强需自行处理幂等、空回滚、悬挂等边界问题。适用场景高并发核心链路如电商下单扣库存、金融支付扣款。Saga 模式原理将长事务拆为多个本地事务顺序执行每个步骤对应一个补偿操作失败时反向执行补偿恢复一致性。分编排式中心化协调器和协同式事件驱动。优缺点无长锁、适合长链路但无隔离性中间状态对外可见补偿逻辑复杂。适用场景订单履约、物流调度、跨境支付等长流程业务。可靠消息最终一致性本地消息表业务操作与消息记录写入同一本地事务后台任务轮询投递到 MQ消费端幂等处理。事务消息由 MQ 本身提供事务支持如 RocketMQ 半消息机制解耦了业务库与消息表是本地消息表的升级版。适用场景跨服务异步解耦如注册送积分、下单后发券、数据同步。最大努力通知原理对下游多次重试通知失败后进入死信/告警/人工介入尽最大努力达成一致。适用场景一致性要求极低的场景如短信/邮件通知、支付结果回调。3. 框架级方案SeataSeata 是阿里开源的分布式事务框架集成了多种模式可根据场景灵活选择表格下载为表格导出为图片模式一致性侵入性适用场景AT最终一致零侵入加注解即可90% 普通微服务 CRUDTCC最终一致高侵入金融支付等高并发核心业务SAGA最终一致中长流程业务XA强一致低低并发强一致场景AT 模式通过代理数据源、解析 SQL 自动生成undo_log实现反向补偿对业务几乎无侵入是目前微服务架构下最常用的方案之一。选型建议不能容忍任何不一致→ 2PC / XA牺牲性能换强一致希望业务少改造、快速落地→ Seata AT 或本地消息表可接受业务侵入、链路短且并发高→ TCC链路长、步骤多→ Saga只需异步通知下游→ 可靠消息 / 最大努力通知生产环境最佳实践优先通过架构设计如聚合服务、避免跨库写规避分布式事务无法规避时再按需选型。