面试题：微服务架构下如何处理分布式事务

Question

在微服务架构中，当一个业务操作涉及多个微服务的状态变更时，分布式事务处理变得复杂。请描述你所了解的分布式事务解决方案，如两阶段提交、TCC 等，并分析它们的优缺点。

Answer 1

两阶段提交（2PC）

1. 原理：
   • 第一阶段（投票阶段）：协调者向所有参与者发送事务内容，询问是否可以提交事务，参与者根据自身情况反馈是否准备好提交。
   • 第二阶段（提交阶段）：如果所有参与者都反馈准备好提交，协调者发送提交指令，参与者执行提交操作；如果有任何一个参与者反馈不能提交，协调者发送回滚指令，参与者执行回滚操作。
2. 优点：
   • 实现相对简单，能够保证强一致性。在正常情况下，可以确保所有参与者要么都提交事务，要么都回滚事务。
3. 缺点：
   • 单点问题：协调者是整个 2PC 机制的核心，一旦协调者出现故障，整个分布式事务无法进行。例如协调者在发送提交指令前崩溃，参与者会一直处于等待状态。
   • 同步阻塞：在整个事务处理过程中，参与者在等待协调者指令期间，资源被锁定无法释放，会造成资源的浪费。例如在等待提交或回滚指令时，数据库连接等资源不能用于其他事务。
   • 性能问题：由于需要等待所有参与者的响应，整个事务处理的性能较低，特别是在参与者数量较多或者网络延迟较大的情况下。

TCC（Try - Confirm - Cancel）

1. 原理：
   • Try 阶段：主要是对业务系统做检测及资源预留。例如在一个涉及订单和库存的分布式事务中，Try 阶段订单服务创建订单记录并锁定，库存服务冻结相应库存。
   • Confirm 阶段：确认执行业务操作，在 Try 阶段成功的前提下，执行真正的业务操作。如订单服务确认订单，库存服务扣减库存。
   • Cancel 阶段：如果 Try 阶段有任何一个操作失败，或者在后续过程中出现异常，执行 Cancel 操作，释放 Try 阶段预留的资源。如订单服务删除订单记录，库存服务解冻库存。
2. 优点：
   • 性能较好：不需要长时间锁定资源，资源在 Try 阶段预留后，Confirm 或 Cancel 阶段可快速释放，提高了系统的并发处理能力。
   • 灵活性高：业务代码可根据自身逻辑实现 Try、Confirm 和 Cancel 操作，更符合复杂业务场景的需求。例如不同业务模块的资源预留和释放逻辑可能差异较大，TCC 可以很好地适应。
3. 缺点：
   • 开发成本高：需要业务开发者自己实现 Try、Confirm 和 Cancel 三个操作，对业务代码侵入性强。例如每个涉及分布式事务的业务方法都要实现这三个阶段的逻辑，代码量增加且逻辑复杂。
   • 一致性问题：虽然大多数情况下能保证最终一致性，但在极端情况下，如 Confirm 或 Cancel 阶段出现部分失败，可能会导致数据不一致。例如某个微服务在 Confirm 时网络中断，可能导致部分资源已确认操作，部分未确认，需要额外的补偿机制来处理。