秒杀相信大家都不陌生，商家会发布一些价格低廉、数量很少的商品，吸引用户抢购，例如每年双十一活动就属于典型的秒杀活动。还有类似春节12306抢票、小米手机限量发售等都可以理解为“秒杀”。

秒杀特点是持续时间短，抢购人数多，参与人数大大高于商品数量。抢购开始前后大量用户请求涌入，极易给服务造成巨大压力。如果系统设计不当，还容易造成超卖、数据丢失等问题。

本文我们主要讨论在秒杀的高并发场景下，传统订单架构存在的性能瓶颈，如何利用redis、MQ等中间件对系统做优化，解决缓存加速、防止重复提交、排队下单、超卖、少卖、削峰、异步下单等核心问题。

秒杀业务流程简介

秒杀总体业务流程可以简述为

1. 商户创建秒杀活动，设定秒杀时间段，选择本次活动的商品，设置折扣、库存等；

4. 如果库存充足，则创建订单成功；否则秒杀失败

5. 提交订单后超时未支付，系统会自动关闭订单，回滚库存。

秒杀页面主要分为：

（1）首页秒杀活动列表

（2）商品详情页

普通订单系统

我们来看看普通订单系统是如何处理订单请求的.

订单下单流程图

流程分析

在springcloud环境下，普通订单下单流程可以总结为：

1. 用户确认订单、提交订单，发送下单请求至订单微服务；

2.订单服务会调用用户服务做一系列业务校验，如账号是否异常等；

还会调用商品服务，校验商品信息；

商品服务又会调用活动服务，校验优惠券、计算优惠等；

3.各服务从MySql获取业务数据，进行业务计算、业务校验；

4.生成订单，最后将订单数据入库。

瓶颈分析

普通订单系统分析

以上是传统微服务架构订单业务的经典流程，在用户量不多、并发不高的正常业务场景下，支撑起正常的业务需求是没问题的。可以通过部署集群、数据库分库分表和读写分离、sql调优、硬件升级等方式，进一步提高系统稳定性和抗并发能力。

但是对于秒杀业务场景，由于秒杀活动特点是商品库存少，参与人数多，在秒杀开始前后，系统的瞬间请求流量飙升，对后端服务尤其是数据库造成很大压力，如果不能进行有效削峰、限流，所有请求一次性到某一台服务器或数据库上，服务很有可能出现卡顿、不可用甚至宕机的可能，给用户造成不良体验。

普通订单系统处理秒杀业务的瓶颈

数据库负担过重

从上图可以看出，仅一个下单请求，所有服务的查询、修改等都是直接操作mysql，没有用到缓存，秒杀开始，系统瞬间承受平时数十倍甚至上百倍的流量，导致mysql cpu占用升高，压力过重，直接拖慢所有系统服务。