作者回复: 这位同学你好，你的问题很好。这个问题其实涉及到一个系统各模块的职责问题，接单和引擎的职责，已经是负责接入并转移生产，的确这个过程可能出现问题，但是如果是合法性校验错误问题，我个人认为这个是需要前置处理的，位置是在进入结算页，以及点击结算生成订单快照那些步骤，因为订单其实就是一份电子合同，如果是在后续环节出现问题，比如钱计算错了，这种情况往往平台还需要履约的。

作者回复: 您好，同学。高并发下减库存要首先确认下场景，在限时秒杀场景使用消息队列，会不会出现消息延迟导致超卖的问题？你的业务是否接收呢。如果是普通场景，流程允许一定范围的超卖，使用消息队列我觉得也是可以的，当然采用缓存也是可以的。在极客时间上有个老师专栏专门讲了秒杀系统的设计，我也学习了，推荐给你。

作者回复: 这位同学你问的问题都很切入实际的关键点哦，给你个赞。第一个问题，正常的下单流程是在订单转移以后在减库存的，流程是允许超卖的出现，这个和降价限时秒杀是不一样的。第二个问题，高订单量采用的是分而治之的策略，接单服务只负责把订单存下来，并创建首任务，只负责这一个单一职责，后续操作则采用异步多线程的方式处理，这与万级架构中，读写操作都访问到同一数据库是有本质的区别的。感谢你的留言和支持。

作者回复: 订单号生成策略的设计与实现也是非常巧妙的，支撑数亿级的高并发设计，你可以参考下美团的案例。我提供的基本思路是一种生产者和消费者得理念。

作者回复: 你的建议非常好，一看你就是好学的同学。谢谢你的支持，我会加油，争取有更好的分享给大家。