企业官网建设流程全解析

已完成分析，共参考 6 篇资料

常见的分布式事务方案可以从“刚性事务（追求强一致性）”和“柔性事务（追求最终一致性）”两个维度来理解。在微服务和多数据库场景下，需要根据业务对一致性、性能、侵入性的要求做取舍。

1. 刚性事务（强一致性，基于 ACID）

• 2PC（两阶段提交）

  • 原理：协调者统一调度，第一阶段询问所有参与者是否准备好（参与者锁定资源但不提交）；第二阶段根据投票结果统一提交或回滚。
  • 优缺点：强一致、对业务侵入小；但同步阻塞、锁资源时间长、协调者单点故障风险，性能较差。
  • 适用场景：低并发、对数据强一致性要求极高的场景，如银行核心转账、跨库结算。

• 3PC（三阶段提交）

  • 原理：在 2PC 基础上增加CanCommit预提交阶段和超时机制，分 CanCommit / PreCommit / DoCommit 三阶段。
  • 优缺点：降低了协调者宕机导致的阻塞风险；但协议更复杂，网络分区下仍可能不一致，工程落地较少。

• XA 模式：本质是数据库层面的 2PC 实现（如 MySQL XA），Seata 也提供了 XA 模式封装，属于强一致方案。

2. 柔性事务（最终一致性，基于 BASE）

• TCC（Try-Confirm-Cancel）

  • 原理：业务层面实现三接口——Try 预留资源、Confirm 确认执行、Cancel 释放/补偿。
  • 优缺点：性能好、无数据库长锁、可对接异构资源；但业务侵入性强，需自行处理幂等、空回滚、悬挂等边界问题。
  • 适用场景：高并发核心链路，如电商下单扣库存、金融支付扣款。

• Saga 模式

  • 原理：将长事务拆为多个本地事务顺序执行，每个步骤对应一个补偿操作；失败时反向执行补偿恢复一致性。分编排式（中心化协调器）和协同式（事件驱动）。
  • 优缺点：无长锁、适合长链路；但无隔离性（中间状态对外可见），补偿逻辑复杂。
  • 适用场景：订单履约、物流调度、跨境支付等长流程业务。

• 可靠消息最终一致性

  • 本地消息表：业务操作与消息记录写入同一本地事务，后台任务轮询投递到 MQ，消费端幂等处理。
  • 事务消息：由 MQ 本身提供事务支持（如 RocketMQ 半消息机制），解耦了业务库与消息表，是本地消息表的升级版。
  • 适用场景：跨服务异步解耦，如注册送积分、下单后发券、数据同步。

• 最大努力通知

  • 原理：对下游多次重试通知，失败后进入死信/告警/人工介入，尽最大努力达成一致。
  • 适用场景：一致性要求极低的场景，如短信/邮件通知、支付结果回调。

3. 框架级方案：Seata

Seata 是阿里开源的分布式事务框架，集成了多种模式，可根据场景灵活选择：

表格

下载为表格

导出为图片

AT 模式通过代理数据源、解析 SQL 自动生成undo_log实现反向补偿，对业务几乎无侵入，是目前微服务架构下最常用的方案之一。

选型建议

• 不能容忍任何不一致→ 2PC / XA（牺牲性能换强一致）
• 希望业务少改造、快速落地→ Seata AT 或本地消息表
• 可接受业务侵入、链路短且并发高→ TCC
• 链路长、步骤多→ Saga
• 只需异步通知下游→ 可靠消息 / 最大努力通知
• 生产环境最佳实践：优先通过架构设计（如聚合服务、避免跨库写）规避分布式事务，无法规避时再按需选型。