《微服务架构下的分布式事务解决方案》

在单体应用中，事务依赖数据库即可。但微服务架构下，一个业务往往涉及多个服务和数据库，传统事务模型不再适用。

1. 分布式事务面临的问题

• 一致性：多个服务要么同时成功，要么同时回滚。
• 可靠性：跨网络、跨系统调用增加失败概率。
• 性能：事务机制不能拖慢整体吞吐量。

2. 常见解决方案

1. 两阶段提交（2PC）

   • 原理：协调者先准备（Prepare），再提交（Commit）。
   • 优点：强一致性。
   • 缺点：阻塞严重，性能差，单点问题明显。

2. TCC（Try-Confirm-Cancel）

   • Try：预留资源。
   • Confirm：确认执行。
   • Cancel：回滚操作。
   • 优点：业务灵活，减少锁资源。
   • 缺点：实现复杂，需侵入业务逻辑。

3. 可靠消息最终一致性

   • 通过消息队列保证事务完成。
   • 业务操作和消息发送绑定，消费失败可重试。
   • 优点：性能较好，系统解耦。
   • 缺点：一致性是“最终”而非强一致。

4. 本地消息表方案

   • 在本地事务中记录消息，定时任务轮询发送。
   • 缺点：需要额外表和补偿机制。

3. 实际落地建议

• 强一致性场景（如金融交易）考虑 TCC。
• 大部分电商场景用消息队列方案即可。
• 提前设计好补偿机制，避免“悬挂事务”。

结论：分布式事务没有完美方案，需要根据业务容忍度选择一致性等级。