关于项目中异步下单的总结

异步处理

所谓异步处理，就是将要处理的信息封装成一个消息体，放到消息队列里，然后再异步的从消息队列里取消息并处理。

异步处理优点

1）可以进行流量削峰

2）吞吐量提高（所谓吞吐量提高，就是1s以内可以处理更多请求）

应用1：

我们的这个探店优选项目中，对于订单模块的同步处理逻辑是这样的：完成下单的整体逻辑是，判断库存是否充足、判断是否已经下过单，如果都是满足要求的，那么就在数据库中扣减库存、在订单表里新增订单，最后将订单id返回给前端。这样存在两个问题：

1. 吞吐量低。因为完成一个请求，需要完成以上所有动作，时间花费长。

2. 数据库压力大。如果有大量请求涌入服务器，如果每个请求都立即访问数据库进行扣减库存+写入订单的操作，对数据库的压力是巨大的。

因此，根据以上问题，我们可以想到异步处理来解决。判断完库存是否充足、判断是否已经下过单后，将订单id、用户id、优惠券id封装成一个消息体，放到消息队列里。给用户返回类似“抢购请求发送成功”的结果。而在消息队列中，将收到的信息一个个的写入数据库中。这样与同步对比，可以带来的好处是：

• 同步方式：大量请求快速占满数据库框架开启的数据库连接池，同时修改数据库，导致数据库读写性能骤减。

• 异步方式：一条条消息以顺序的方式写入数据库，连接数几乎不变（当然，也取决于消息队列消费者的数量）。防止写表量过大。

这可以理解为异步处理带来的流量削峰。不管并发量有多高，数据库按照他的处理能力，从消息队列中拿取消息进行处理。

异步处理缺点

1）消息队列处理消息前和处理完消息后，要如何告知用户？

• 让前端在提交订单后，显示一个“排队中”。

• 同时，前端不断请求 检查用户和商品是否已经有订单 的接口，如果得到订单已经处理完成的消息，页面跳转抢购成功。

应用1：

探店优选项目在消息队列还没处理消息前，就直接生成订单id返回给前端。这没有考虑到，如果消息队列处理消息失败了，那么对于这个已生成的订单号要怎么处理？另外，在redis中判断库存是否充足、判断是否已经下过单。然后直接更新缓存。如果消息队列处理消息失败了，那么这个缓存要如何和数据库保持一致性？

我看到别人的实现版本是，在缓存中判断库存是否充足、判断是否已经下过单后，不是直接返回前端一个订单id，而是让前端显示一个“排队中”。消息队列处理消息的逻辑是，通过数据库再一次判断库存是否充足、判断是否已经下过单，然后在数据库中扣减库存、生成订单。并且在缓存中将库存减1，优惠券id多添加一个用户id。当前端不断请求，一旦判断出缓存中有该用户id了，表示下单成功。否则不断请求。

参考

秒杀系统实战（五）| 如何优雅的实现订单异步处理-腾讯云开发者社区-腾讯云 (tencent.com)