糟糕，老板让我设计一个亿级用户秒杀系统！

个人从事电商行业十几年，经历过大大小小的促销活动和秒杀上百次，每次做秒杀瞬时访问量会翻数十倍，甚至数百倍。对系统架构是巨大的考验，期间也曾经历过系统宕机，甚至整体雪崩。

图片来自 Pexels

那么我们怎么设计秒杀系统，才能保证秒杀系统的高性能和稳定性，同时还要保证日常业务不受影响呢?

先看看秒杀场景特点：秒杀开始前几分钟，大量用户开始进入秒杀商品详情页面，很多人开始频繁刷新秒杀商品详情页，这时秒杀商品详情页访问量会猛增。

秒杀开始，大量用户开始抢购，这时创建订单，扣库存压力会显著增大。实际上，秒杀场景基本都是秒杀参与人多，秒杀成功的人却寥寥无几，经常是几十万人或者更多人抢几百个商品库存。

那么我们曾经是怎么设计秒杀系统的呢?主要涉及以下几个方面：

秒杀业务流程上的考虑

由于参加秒杀的商品售卖价格非常低，基本都是“抢到即赚到”，成功下单后却不付款的情况非常少。

所以我们采用下单减库存的方案，下单时扣减库存，然后再进行支付。假如真有个别订单不付款怎么办?

没关系，秒杀好活动最主要的目的是吸引流量，个别订单不支付对秒杀活动本身影响不大。

况且，没支付剩下的库存还可以做为普通商品继续售卖。不过要注意对机器人和自动脚本的防御，后面会详细介绍。

页面静态化

“秒杀开始前几分钟，大量用户开始进入秒杀商品详情页面，很多人开始频繁刷新秒杀商品详情页，这时秒杀商品详情页访问量会猛增”。

如果请求全部打到后端服务，那后端服务的压力会非常大(后端服务要处理业务逻辑，而且还要访问数据库，吞吐量比较低)。

考虑到秒杀是运营同学提前安排的活动，要秒杀哪些商品、商品价格等信息在秒杀活动开始前已经确定下来。

所以我们可以把秒杀商品详情页做成静态页面，把商品详情、商品价格等参数、评论评价等信息全部放在这个静态页面里，然后把这个静态页面上传到 CDN 上预热。

CDN 是内容分发网络，可以简单理解成互联网上的巨大的缓存，用于存放静态页面、图片、视频等，可以显著提高访问速度，用 CDN 扛流量，这样大量的商品详情页的访问请求就不用访问自己的网站(源站)。

这样既可以提高访问速度，也没有给网站增加压力，同时也减少了网站带宽压力。

请求拦截

前端页面，相关按钮点击后置灰，防止重复提交。

网关(Zuul，Nginx)层，为了避免前端恶意请求，比如一些攻击脚本，在网关层要对下单等接口按 userID 限流，几秒钟只能访问一次。

考虑到秒杀场景参与人多，秒杀成功的人极少，我们可以把绝大部分抢购下单请求在网关层直接拒掉，按秒杀失败处理。这样就极大减少了后端服务的压力。

假设秒杀库存是 200 个，我们可以只放行 200 个请求到后端服务。要注意，为了尽量避免库存被机器人和自动脚本抢走，200 个请求不能在秒杀开始瞬间同时放行，可以分段放行。

比如秒杀开始后随机选取 100ms 内的 5 个请求放行(这 100ms 内的其他请求直接拒掉，按秒杀失败处理)，之后每隔 100ms 放行 5 个请求，4 秒钟可以放行完 200 个请求。

分段放行，除了限制了机器人和自动脚本，把请求分散在各个时间段，还进一步缓解了后端服务的压力。

分段放行总时间不能太长，假如每 100ms 放行 1 个请求，放行完所有 200 个请求需要 20 秒时间，这样用户就会明显感知到下单早的人没秒杀成功，下单晚的人反而秒杀成功了，用户体验会变差。

另外，秒杀过程网关压力会比较大，网关可以做成集群，多节点分摊访问压力。

后端服务设计

如果秒杀库存只有 200，经过网关拦截，再加上采用分段放行的方式，对于后端服务基本没什么压力了，日常的后端服务就完全可以支撑秒杀活动了。不用再做更复杂的设计。

不过，假如秒杀库存有几万个，放行的下单请求就有几万个，为了用户体验放行总时间也不能太长，这时后端服务该怎么设计呢?

这时主要压力就在数据库了，扣减库存压力，创建订单压力。

库存可以放到 Reids 缓存中，来提高扣减库存吞吐能力。对于热点商品的库存可以利用 Redis 分片存储。

创建订单可以走异步消息队列。后端服务接到下单请求，直接放进消息队列，监听服务取出消息后，先将订单信息写入 Redis，每隔 100ms 或者积攒 100 条订单，批量写入数据库一次。

前端页面下单后定时向后端拉取订单信息，获取到订单信息后跳转到支付页面。

用这种批量异步写入数据库的方式大幅减少了数据库写入频次，从而明显降低了订单数据库写入压力。

隔离

业务隔离

从业务上把秒杀和日常的售卖区分开来，把秒杀做为营销活动，要参与秒杀的商品需要提前报名参加活动。

（编辑：ASP站长网）