微服务架构下，数据分散在多个独立的服务中，传统的本地事务无法保证跨服务操作的一致性，因此需要引入分布式事务的解决方案。以下是几种主流的处理方式，各有适用场景和权衡。
1. 两阶段提交（2PC）
原理：2PC 是一种强一致性协议，分为“准备”和“提交”两个阶段。协调者询问所有参与者是否可以提交事务，只有全部同意才真正执行提交，否则回滚。
优点：保证强一致性。
缺点：同步阻塞、单点故障风险高、性能较差，不适合高并发场景。
适用场景：对一致性要求极高，且参与方较少的系统，如传统金融系统。
2. TCC（Try-Confirm-Cancel）
原理：TCC 要求每个服务实现三个操作：Try（尝试）、Confirm（确认）、Cancel（取消）。Try 阶段预留资源，Confirm 真正提交，Cancel 释放资源。
优点：灵活性高，支持最终一致性，性能优于 2PC。
缺点：开发复杂度高，需要业务逻辑拆解为三阶段，容易出错。
建议：用于资金交易、库存扣减等关键业务，需谨慎设计补偿逻辑。
3. 基于消息队列的最终一致性
原理：通过可靠消息系统（如 RocketMQ、Kafka）保证事务消息的传递，发送方将本地事务与消息发送绑定，接收方消费消息后执行对应操作。
实现方式：
本地消息表：事务与消息写入同一数据库，确保原子性。 事务消息：利用消息中间件提供的事务消息功能（如 RocketMQ）。优点：解耦服务，异步高效，适合高并发场景。
注意点：需处理消息重复消费、幂等性问题。
4. Saga 模式
原理：Saga 将一个分布式事务拆分为多个本地事务，每个步骤都有对应的补偿操作。若某步失败，则逆序执行补偿事务来回滚。
两种实现：
编排式（Choreography）：各服务监听彼此事件，无中心控制。 协调式（Orchestration）：由一个协调器驱动整个流程。优点：长事务支持好，适用于流程较长的业务（如订单处理）。
挑战：补偿逻辑需完备，某些操作难以完全回滚（如已发短信）。
基本上就这些。选择哪种方案取决于业务对一致性、性能、开发成本的要求。没有银弹，关键是根据实际场景权衡取舍。比如高并发系统优先考虑消息队列 + 最终一致性，而核心支付流程可能更适合 TCC 或 Saga。
