分布式事务解决方案

分布式事务是指跨多个服务或数据库的事务操作，需要保证 ACID（原子性、一致性、隔离性、持久性）特性。由于微服务架构的普及，分布式事务成为系统设计的难点之一。以下是常见的 分布式事务解决方案，包括 Seata 及其替代方案：

1. 两阶段提交（2PC, Two-Phase Commit）

• 原理：
  协调者（Coordinator）先询问所有参与者（Participants）是否可以提交（Prepare Phase），如果全部同意，则发送提交命令（Commit Phase），否则回滚。
• 优点：强一致性，适合传统数据库分布式事务（如XA协议）。
• 缺点：
  • 同步阻塞：参与者必须等待协调者指令，可能长时间锁定资源。
  • 单点故障：协调者宕机会导致事务阻塞。
• 适用场景：数据库层分布式事务（如MySQL XA、Oracle XA）。

2. 三阶段提交（3PC, Three-Phase Commit）

• 改进点：在2PC基础上增加 CanCommit 阶段，减少阻塞时间。
• 优点：降低阻塞概率，比2PC更健壮。
• 缺点：仍然存在数据不一致的可能（如网络分区问题）。

3. TCC（Try-Confirm-Cancel）

• 原理：
  业务层面将事务拆分为 Try（预留资源）→ Confirm（提交） / Cancel（回滚） 三个阶段。
• 优点：
  • 无全局锁，性能较高。
  • 适用于高并发场景（如电商扣库存、支付）。
• 缺点：
  • 业务侵入性强，需要手动实现补偿逻辑。
  • 可能出现 空回滚 或 悬挂问题。
• 框架：Seata TCC、ByteTCC、Hmily。

4. SAGA 模式

• 原理：
  长事务拆分为多个本地事务，每个事务执行后触发下一个事务，失败时逆向补偿。
• 优点：
  • 适合 长事务（如订单+库存+物流）。
  • 无锁设计，异步执行。
• 缺点：
  • 不保证隔离性（可能脏读）。
  • 补偿逻辑复杂。
• 实现：Seata Saga、Apache ServiceComb Saga。

5. 本地消息表（异步确保）

• 原理：
  事务发起方在本地数据库记录消息，通过定时任务或MQ异步通知其他服务，确保最终一致性。
• 优点：
  • 无侵入，依赖数据库事务。
  • 适合 低耦合 场景（如用户注册后发短信）。
• 缺点：
  • 依赖消息可靠性（可能重复消费）。
  • 时效性较差。
• 实现：RocketMQ 事务消息、自研本地消息表。

6. 最大努力通知（Best Effort）

• 原理：
  服务A通知服务B，若失败则 重试N次，最终不保证严格一致（允许人工介入）。
• 适用场景：对一致性要求不高的场景（如支付结果通知）。

7. Seata（AT 模式）

• 原理：
  • 阶段1：Seata 拦截业务SQL，生成 undo_log（回滚日志），本地提交。
  • 阶段2：若所有分支成功，异步删除日志；否则用 undo_log 回滚。
• 优点：
  • 近乎零侵入，像本地事务一样使用。
  • 支持全局锁防脏写。
• 缺点：
  • 依赖 undo_log 表，性能低于TCC。
  • 不适用于跨语言微服务（需Java生态）。

8. 其他方案对比

如何选择？

• 强一致性 → 2PC/XA（但性能差）。
• 高并发+最终一致 → TCC 或 Seata AT。
• 长事务+补偿 → SAGA。
• 跨语言/低侵入 → 本地消息表或MQ事务消息。

Seata 是Java生态的 一站式解决方案，支持AT、TCC、SAGA，适合Spring Cloud/Alibaba用户。其他语言（如Go）可考虑TCC或SAGA模式。