高并发电商下订单与库存架构解析

高并发电商下订单与库存架构解析

高并发电商下订单与库存<a href='/tag/arch.html'>架构</a>解析

大家都知道,我们在写下订单的时候,需要去查一下库存,如果库存有,就继续执行下订单的操作,如果没有就返回给用户卖完了,那么下订单这个逻辑必然依赖查库存这个逻辑,在高并发的情况下,一旦查库存逻辑奔溃,必然影响下订单。

传统订单处理流程

高并发电商下订单与库存<a href='/tag/arch.html'>架构</a>解析

那么怎么改变呢,让订单服务与库存服务解耦,我们中间加一个MQ消息队列。

订单库存分离架构设计

1、在订单服务新增订单后,订单的状态是“已开启”,然后发布一个Order Created事件到消息队列上

高并发电商下订单与库存<a href='/tag/arch.html'>架构</a>解析

2、库存服务在监听到消息队列OrderCreated中的消息,将库存表中商品的库存减去下单数量,然后再发送一个Stock Locked事件给消息队列。

高并发电商下订单与库存<a href='/tag/arch.html'>架构</a>解析

3、订单服务接收到Stock Locked事件,将订单的状态改为“已确认”

高并发电商下订单与库存<a href='/tag/arch.html'>架构</a>解析

同样,这里我们也是会利用手动确认消息来保证消息的投递可靠性。

至此,已经全部搞定了。我们看一下和正常的服务调用对比如何:

1、订单服务不再直接依赖于库存服务,而是将下单事件发送到MQ中,让库存监听。

2、订单服务能真正的作为一个模块独立运行。

3、解决了并发问题,而且MQ的队列处理效率非常的高。

但是也存在下面的问题:

1、用户体验改变了:因为使用事件机制,订单是立即生成的,可是很有可能过一会,系统会提醒你没货了。。这就像是排队抢购一样,排着排着就被通知没货了,不用再排队了。

2、数据库可能会存在很对没有完成下单的订单。

最后,如果真的要考虑用户体验,并且不想数据库存在很多不必要的数据,该怎么办?

那就把订单服务和库存服务聚合在一起吧。解决当前的问题应当是首先要考虑的,我们设计微服务的目的是本想是解决业务并发量。而现在面临的却是用户体验的问题,所以架构设计也是需要妥协的。

最主要是,我们是经过思考和分析的,每个方案能做到哪种程度,能应用到哪种场景。正所谓,技术要和实际场景结合,我们不能为了追求新技术而生搬硬套。

技术是为了解决实际业务场景面临的问题,技术服务于业务。

{{collectdata}}

网友评论0

阿里云香港主机,免备案大优惠 打开浏览器开发html,体验云开发的乐趣bfweditor 打开浏览器即可开发php,bfwstudio
其他文章