面试题：基于Spring Cloud微服务架构设计面向复杂业务场景的接口数据一致性解决方案

Question

假设你正在开发一个涉及多个微服务交互的复杂业务系统，如电商的订单处理系统，包含订单创建、库存扣减、支付等多个服务。在这种场景下，接口调用过程中可能出现部分成功部分失败的情况，如何保证数据的最终一致性？请基于Spring Cloud相关技术，详细阐述你设计的数据一致性解决方案，包括所采用的分布式事务模式（如TCC、Saga等），具体实现流程以及如何处理异常情况和补偿机制等。

Answer 1

分布式事务模式选择

1. Saga模式：适用于长事务场景，将一个大事务分解为多个本地事务，每个本地事务都有对应的补偿操作。对于电商订单处理系统这种涉及多个微服务交互且业务流程长的场景较为合适。它允许每个微服务独立完成本地事务，即使部分服务失败，也能通过补偿操作回滚已成功的部分。
2. TCC模式：Try - Confirm - Cancel，Try阶段做资源预留，Confirm阶段确认提交，Cancel阶段回滚。但它对业务侵入性较强，需要业务代码实现Try、Confirm、Cancel三个操作，相比之下Saga模式更符合订单处理系统这种复杂业务场景的灵活性需求。

具体实现流程（以Saga模式为例）

1. 订单创建：
   • 订单服务接收到创建订单请求，创建订单记录并设置为“创建中”状态，生成唯一订单ID。
   • 通过消息队列（如RabbitMQ）发送“订单创建成功”消息到库存服务和支付服务对应的队列。
2. 库存扣减：
   • 库存服务监听订单创建成功消息队列，接收到消息后，根据订单ID和商品信息检查库存是否充足。
   • 如果充足，扣减库存并更新库存状态，然后发送“库存扣减成功”消息到支付服务队列；如果不足，发送“库存不足”消息到订单服务的补偿队列。
3. 支付：
   • 支付服务监听库存扣减成功消息队列，接收到消息后，发起支付流程。
   • 支付成功后，更新订单状态为“支付成功”，并发送“支付成功”消息到订单服务；支付失败则发送“支付失败”消息到订单服务的补偿队列。
4. 订单最终状态更新：
   • 订单服务监听支付成功消息，接收到后将订单状态更新为“已完成”。

异常情况处理及补偿机制

1. 库存扣减异常：
   • 订单服务接收到“库存不足”消息，将订单状态更新为“库存不足，创建失败”。
   • 调用订单创建的补偿操作，如删除已创建的订单记录（如果允许）或标记为无效订单。
2. 支付异常：
   • 订单服务接收到“支付失败”消息，将订单状态更新为“支付失败”。
   • 调用库存扣减的补偿操作，即增加已扣减的库存。
3. 消息丢失处理：
   • 引入消息确认机制，发送方等待接收方的确认消息。如果未收到确认，进行消息重发。
   • 每个微服务记录消息处理日志，用于排查和恢复丢失消息的处理。
4. 系统崩溃处理：
   • 各微服务启动时，检查未完成的事务记录。
   • 对于订单服务，若订单处于“创建中”状态，根据其他服务的日志或状态判断下一步操作，如调用补偿操作或重新发起后续流程。

在Spring Cloud中，可使用Spring Cloud Stream整合消息队列实现消息的可靠传递，利用Spring Boot的事务管理实现本地事务，从而构建基于Saga模式的数据一致性解决方案。