面试题：分布式系统微服务架构下如何处理跨服务事务以保证ACID一致性

Question

假设你正在设计一个电商微服务系统，其中订单服务、库存服务等多个微服务之间存在跨服务事务。请描述你会采用什么方案来保证这些跨服务事务满足ACID一致性，包括可能用到的技术和具体实现思路。

Answer 1

1. 两阶段提交（2PC）方案

技术

• 协调者：一般是一个独立的服务，负责协调各个参与事务的微服务（参与者）。
• 参与者：订单服务、库存服务等各个微服务。

实现思路

• 准备阶段（Prepare）
  • 协调者向所有参与者发送 Prepare 消息。
  • 参与者接收到 Prepare 消息后，执行事务操作，但不提交，记录日志，然后向协调者回复 Yes 表示准备就绪，或者 No 表示失败。
• 提交阶段（Commit）
  • 如果协调者收到所有参与者的 Yes 回复，向所有参与者发送 Commit 消息，参与者收到后正式提交事务。
  • 如果有任何一个参与者回复 No，或者在规定时间内没有收到所有参与者的回复，协调者向所有参与者发送 Rollback 消息，参与者回滚事务。

2. 三阶段提交（3PC）方案

技术

• 协调者：同样是独立服务，负责协调事务。
• 参与者：各微服务。

实现思路

• 询问阶段（CanCommit）
  • 协调者向参与者发送 CanCommit 询问是否可以进行事务操作。
  • 参与者检查自身状态，如果可以，回复 Yes，否则回复 No。
• 预提交阶段（PreCommit）
  • 若协调者收到所有参与者的 Yes 回复，发送 PreCommit 消息。
  • 参与者接收到 PreCommit 消息后，执行事务操作但不提交，记录日志，然后回复 Ack。
• 提交阶段（DoCommit）
  • 如果协调者收到所有参与者的 Ack 回复，发送 DoCommit 消息，参与者正式提交事务。
  • 如果有参与者回复 No 或超时未收到所有 Ack，协调者发送 Abort 消息，参与者回滚事务。

3. TCC（Try - Confirm - Cancel）方案

技术

• 业务层面的补偿机制：通过在业务代码中实现 Try、Confirm、Cancel 三个操作来完成事务。

实现思路

• Try 阶段
  • 订单服务执行 Try 操作，如预占库存（不实际扣减）、生成预订单。
  • 库存服务执行 Try 操作，如冻结库存。
• Confirm 阶段
  • 如果所有微服务的 Try 操作都成功，订单服务执行 Confirm 操作，正式创建订单。
  • 库存服务执行 Confirm 操作，实际扣减库存。
• Cancel 阶段
  • 如果任何一个微服务的 Try 操作失败，订单服务执行 Cancel 操作，取消预订单。
  • 库存服务执行 Cancel 操作，解冻库存。

4. 基于消息队列的最终一致性方案

技术

• 消息队列：如 RabbitMQ、Kafka 等。

实现思路

• 订单创建：订单服务创建订单成功后，向消息队列发送一条包含订单信息及库存扣减信息的消息。
• 库存服务消费：库存服务监听消息队列，获取消息后执行库存扣减操作。
• 补偿机制：如果库存服务消费消息失败，消息队列可以重试。也可以设置一个定时任务，定期检查订单状态和库存状态，对不一致的情况进行补偿操作，如订单已创建但库存未扣减，重新发起库存扣减请求。