微服务实践中，用户购买记录如何避过错误回溯？

2023-11-04 04:05:43

正文

现代电商系统都是一个复杂的软件系统，背后都有数不清的技术细节。这些技术细节又取决于具体的业务背景，而我正好接到一个背景非常复杂的订单。

我心想，这不就是简单的一个用户下单吗，我有订单模块，也有用户模块，有用户当然也有商品，在确保库存富余的情况下，订单就可以送出。那么只要我扣减库存、发送消息、更新订单就可以完成任务了。

就这样，我按照业务逻辑和流程图，麻利的写了接口实现。但当我提交之后，老板就跑来跟我说，公司内部的追查系统已经收到了不少错误日志。

“怎么可能会出问题呢？这业务逻辑简直太清晰了，我哪会写错？”我只能不断的排查问题，无非就是看看哪一步没实现、写错了吧。

检查了大半天，我终于发现，原来是每个步骤检查完之后，都要提交事务，这样才会执行扣减库存、发送消息、更新订单。但是，事务是靠不住的，提交了也不会一定执行，一个事务执行期间，另一个事务已经将消息发送出去了，但是扣减库存又失败了。也就是说，一旦发生这种情况下，那么将会出现货都卖出去了，但是库存并没有减少。

原来，面对这样的并发场景，我选择的事务处理策略，仅仅只能在单一数据库下保证操作的顺序性，而并不能保证并发操作的一致性和安全性。实际上，数据库的各个操作步骤之间，事务并不能保证处理过程的可视性。

谈到保证并发操作的顺序性，就不得不提一下分布式事务，分布式事务中最重要的就是两阶段提交，即：当且仅当所有的参与者都确认成功时，最终事务才真正提交。

这时，我想起以前听一位做电商架构的大佬说过，在微服务中处理订单，一般都是使用消息队列。这样，所有操作都会变为异步操作，在扣减库存、发送消息、更新订单之后，产生三条消息，然后用分布式事务管理平台来管理这些消息，这样就能保证所有操作都执行成功了。

接下来，我将针对用户购买场景，结合实际案例，向你介绍如何利用微服务架构、消息队列和分布式事务来保证用户购买记录的正确性。

微服务架构设计

微服务架构将电商系统拆分为多个独立的服务，每个服务负责不同的业务功能，如用户模块、商品模块、订单模块等。这样的好处是，每个服务可以独立开发、部署和维护，便于扩展和升级。

消息队列的应用

消息队列是一种异步消息传递机制，它允许服务之间交换消息，而无需等待对方的响应。在电商系统中，我们可以使用消息队列来解耦用户购买过程中的不同步骤。例如，当用户提交订单时，可以将订单信息放入消息队列中，然后由另一个服务负责扣减库存、发送消息和更新订单。这样，即使其中一个服务发生故障，也不会影响其他服务的操作。