我回来啦，前段时间忙得不可开交。这段时间终于能喘口气了，继续把之前挖的坑填起来。写完上一篇秒杀系统（四）：数据库与缓存双写一致性深入分析后，感觉文章深度一下子被我抬高了一些，现在构思新文章的时候，反而畏手畏脚，不敢随便写了。对于未来文章内容的想法，我写在了本文的末尾。

本文我们来聊聊秒杀系统中的订单异步处理。

再也不用担心看完文章不会代码实现啦：

https://github.com/qqxx6661/miaosha

我发现该仓库的star数不知不觉已经超过100啦。❞

我努力将整个仓库的代码尽量做到整洁和可复用，在代码中我尽量做好每个方法的文档，并且尽量最小化方法的功能，比如下面这样：

「这样就像一个可拔插（plug-in）模块一样，尽量让小伙伴们可以复制粘贴，整合到自己的代码里，稍作修改适配便可以使用。」

可以翻阅该系列的第一篇文章，这里不再回顾：

零基础实现秒杀系统（一）：防止超卖

前面几篇文章，我们从「限流角度，缓存角度」来优化了用户下单的速度，减少了服务器和数据库的压力。这些处理对于一个秒杀系统都是非常重要的，并且效果立竿见影，那还有什么操作也能有立竿见影的效果呢？答案是对于下单的异步处理。

在秒杀系统用户进行抢购的过程中，由于在同一时间会有大量请求涌入服务器，如果每个请求都立即访问数据库进行扣减库存+写入订单的操作，对数据库的压力是巨大的。

如何减轻数据库的压力呢，「我们将每一条秒杀的请求存入消息队列（例如RabbitMQ）中，放入消息队列后，给用户返回类似“抢购请求发送成功”的结果。而在消息队列中，我们将收到的下订单请求一个个的写入数据库中」，比起多线程同步修改数据库的操作，大大缓解了数据库的连接压力，最主要的好处就表现在数据库连接的减少：

「这种实现可以理解为是一中流量削峰：让数据库按照他的处理能力，从消息队列中拿取消息进行处理。」

结合之前的四篇秒杀系统文章，这样整个流程图我们就实现了：

我们在源码仓库里，新增一个controller对外接口：

createUserOrderWithMq接口整体流程如下：

消息队列是如何接收消息的呢？我们新建一个消息队列，采用第四篇文中使用过的RabbitMQ，我再稍微贴一下整个创建RabbitMQ的流程把：

真正的下单的操作，在service中完成，我们在orderService中新建createOrderByMq方法：

真正的下单的操作流程为：

「我是如何在redis中记录商品和用户的关系的呢，我使用了set集合，key是商品id，而value则是用户id的集合，当然这样有一些不合理之处：」

大家知道需要做这种操作就好，具体如何在生产环境的redis中存储这种关系，大家可以深入优化下。

「整个上述实现只考虑最精简的流程，不把前几篇文章的限流，验证用户等加入进来，并且默认考虑的是每个用户抢购一个商品就不再允许抢购，我的想法是保证每篇文章的独立性和代码的任务最小化，至于最后的整合我相信小伙伴们自己可以做到。」

接下来就是喜闻乐见的「非正规」性能测试环节，我们来对异步处理和非异步处理做一个性能对比。

首先，为了测试方便，我把用户购买限制先取消掉，不然我用Jmeter（JMeter并发测试的使用方式参考秒杀系统第一篇文章）还要来模拟多个用户id，太麻烦了，不是我们的重点。我们把上面的controller接口这一部分注释掉：

这样我们可以用JMeter模拟抢购的情况了。

「我们先玩票大的！」 在我这个1c4g1m带宽的云数据库上，「设置商品数量5000个，同时并发访问10000次」。

服务器先跑起来，访问接口是http://localhost:8080/createUserOrderWithMq?sid=1&userId=1

启动！

10000个线程并发，直接把我的1M带宽小水管云数据库打穿了！

对不起对不起，打扰了，我们还是老实一点，不要对这么低配置的数据库有不切实际的幻想。

我们改成1000个线程并发，商品库存为500个，「使用常规的非异步下单接口」：

对比1000个线程并发，「使用异步订单接口」：

「可以看到，非异步的情况下，吞吐量是37个请求/秒，而异步情况下，我们的接只是做了两个事情，检查缓存中库存+发消息给消息队列，所以吞吐量为600个请求/秒。」

在发送完请求后，消息队列中立刻开始处理消息：

我截图了在500个库存刚刚好消耗完的时候的日志，可以看到，一旦库存没有了，消息队列就完成不了扣减库存的操作，就不会将订单写入数据库，也不会向缓存中记录用户已经购买了该商品的消息。

那么问题来了，我们实现了上面的异步处理后，用户那边得到的结果是怎么样的呢？

用户点击了提交订单，收到了消息：您的订单已经提交成功。然后用户啥也没看见，也没有订单号，用户开始慌了，点到了自己的个人中心——已付款。发现居然没有订单！（因为可能还在队列中处理）

这样的话，用户可能马上就要开始投诉了！太不人性化了，我们不能只为了开发方便，舍弃了用户体验！

所以我们要改进一下，如何改进呢？其实很简单：

「是不是很小米（滑稽.jpg），暴露了我是miboy的事实」

实现起来，我们只要在后端加一个独立的接口：

我们来试验一下，首先我们请求两次下单的接口，大家用postman或者浏览器就好：

http://localhost:8080/createUserOrderWithMq?sid=1&userId=1

可以看到，第一次请求，下单成功了，第二次请求，则会返回已经抢购过。

因为这时候redis已经写入了该用户下过订单的数据：

我们为了模拟消息队列处理茫茫多请求的行为，我们在下单的service方法中，让线程休息10秒：

然后我们清除订单信息，开始下单：

http://localhost:8080/createUserOrderWithMq?sid=1&userId=1

第一次请求，返回信息如上图。

紧接着前端显示排队中的时候，请求检查是否已经生成订单的接口，接口返回”继续排队“：

一直刷刷刷接口，10秒之后，接口返回”恭喜您，抢购成功“，如下图：

整个流程就走完了。

这篇文章介绍了如何在保证用户体验的情况下完成订单异步处理的流程。内容其实不多，深度没有前一篇那么难理解。（我拖更也有一部分原因是因为我觉得上一篇的深度我很难随随便便达到，就不敢随意写文章，有压力。）

希望大家喜欢，目前来看，整个秒杀下订单的主流程我们全部介绍完了。当然里面很多东西都非常基础，比如数据库设计我一直停留在那几个破字段，比如订单的编号，其实不可能用主键id来做等等。

「所以之后我文章的重点会更加关注某个特定的方面」，比如：

当然，其他内容的文章我也会不断积累总结啦。

「我的公众号包括博客流量非常小，看见最近那么多公众号都很快的发展庞大起来，我也很羡慕，希望大家多多转发支持，在这里谢谢大家啦。

我是一名后端开发工程师。主要关注后端开发，数据安全，爬虫，物联网，边缘计算等方向，欢迎交流。