分布式事务解决方案
分布式事务是指跨多个服务或数据库的事务操作，需要保证 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 | 强一致 | 低 | 低 | 传统数据库（MySQL XA） |
| TCC | 最终一致 | 高 | 高 | 高并发（电商、金融） |
| SAGA | 最终一致 | 中 | 中 | 长事务（订单+物流） |
| 本地消息表 | 最终一致 | 中 | 低 | 异步场景（用户注册+通知） |
| Seata AT | 最终一致 | 中 | 低 | Java微服务（Spring Cloud） |
如何选择？
- 强一致性 → 2PC/XA（但性能差）。
- 高并发+最终一致 → TCC 或 Seata AT。
- 长事务+补偿 → SAGA。
- 跨语言/低侵入 → 本地消息表或MQ事务消息。
Seata 是Java生态的 一站式解决方案，支持AT、TCC、SAGA，适合Spring Cloud/Alibaba用户。其他语言（如Go）可考虑TCC或SAGA模式。