秒杀系统项目实战（八）秒杀系统架构方案之异步解决方案

在上一篇我们介绍了秒杀系统里面的同步解决方案，这一篇我们介绍下秒杀系统里面的异步解决方案。这种方案是比较提倡大家使用的，不多说直接上图：

针对上面的异步秒杀流程，我们来详细介绍下具体的操作

发起秒杀阶段：

1、用户发起秒杀请求

2、服务端验证客户端请求的验证码是否正确，如果不正确，则返回错误信息。如果正确，则进行到下一步。

3、服务端验证客户端是否限流，这里就是判断我们的mq长度，这里我们常用的mq有rabbitmq（rabbitmq每秒的并发可以达到1W左右，性能是非常不错的），如果mq消息队列的长度超过了阈值，则直接返回错误信息。如果没有达到阈值，则进行到下一步。

4、服务端插入一条秒杀记录，并且把秒杀请求发送到mq，并且生成一个token返回给客户端

5、客户端根据token信息进行轮询查询。

异步处理阶段：

1、判断活动是否已经结束，如果结束，根据token信息插入错误信息，客户端会轮询查询到。

2、判断当前请求是否在黑名单内，如果在，根据token信息插入错误信息，客户端会轮询查询到。

3、扣减缓存中的秒杀商品的库存数量，如果扣减失败，根据token信息插入错误信息，客户端会轮询查询到。

4、所有验证都成功，则根据token信息插入正确信息，客户端会轮询查询到。

结算阶段:

1、客户端轮询token，服务端返回了正确的信息，说明有抢购资格了。

2、客户端根据token发起下单请求，服务端针对token进行校验是否有秒杀资格。如果没有则返回错误信息，如果有则添加到购物车里面去，并且给客户端返回正确信息。

提交订单阶段：

1、用户在购物车里面提交订单

2、服务端创建订单，并且入库，同时删除掉token。

3、用户支付

在整个秒杀系统里面，我们的限流做到了最前置，那这样子我们大部分的流量可以在最前端的网关层进行处理，而我们后面的服务实例不需要部署太多。这样整个系统的压力就不会太大。网上很多的文章和帖子中在介绍秒杀系统时，说是在下单时使用异步削峰来进行一些限流操作，那都是在扯淡！因为下单操作在整个秒杀系统的流程中属于比较靠后的操作了，限流操作一定要前置处理，在秒杀业务后面的流程中做限流操作是没啥卵用的。

最后总结下：

1、异步解决方案是目前最推荐大家做的。

2、所有的限流削峰尽量前置，减轻后端系统的压力。