高并发电商下订单与库存架构解析
大家都知道，我们在写下订单的时候，需要去查一下库存，如果库存有，就继续执行下订单的操作，如果没有就返回给用户卖完了，那么下订单这个逻辑必然依赖查库存这个逻辑，在高并发的情况下，一旦查库存逻辑奔溃，必然影响下订单。
传统订单处理流程
那么怎么改变呢，让订单服务与库存服务解耦，我们中间加一个MQ消息队列。
订单库存分离架构设计
1、在订单服务新增订单后，订单的状态是“已开启”，然后发布一个Order Created事件到消息队列上
2、库存服务在监听到消息队列OrderCreated中的消息，将库存表中商品的库存减去下单数量，然后再发送一个Stock Locked事件给消息队列。
3、订单服务接收到Stock Locked事件，将订单的状态改为“已确认”
同样，这里我们也是会利用手动确认消息来保证消息的投递可靠性。
至此，已经全部搞定了。我们看一下和正常的服务调用对比如何：
1、订单服务不再直接依赖于库存服务，而是将下单事件发送到MQ中，让库存监听。
2、订单服务能真正的作为一个模块独立运行。
3、解决了并发问题，而且MQ的队列处理效率非常的高。
但是也存在下面的问题：
1、用户体验改变了：因为使用事件机制，订单是立即生成的，可是很有可能过一会，系统会提醒你没货了。。这就像是排队抢购一样，排着排着就被通知没货了，不用再排队了。
2、数据库可能会存在很对没有完成下单的订单。
最后，如果真的要考虑用户体验，并且不想数据库存在很多不必要的数据，该怎么办？
那就把订单服务和库存服务聚合在一起吧。解决当前的问题应当是首先要考虑的，我们设计微服务的目的是本想是解决业务并发量。而现在面临的却是用户体验的问题，所以架构设计也是需要妥协的。
最主要是，我们是经过思考和分析的，每个方案能做到哪种程度，能应用到哪种场景。正所谓，技术要和实际场景结合，我们不能为了追求新技术而生搬硬套。
技术是为了解决实际业务场景面临的问题，技术服务于业务。
{{collectdata}}
网友评论0