抢购秒杀系统架构设计

类似抢购秒杀类的高并发系统设计经常在面试中问到,面试官主要考察候选人有没有真实相关的经验或有没有深入研究过这类问题。

当真实工作中遇到类似问题时,开发人员脑子里具有相应开发设计概念还是很有必要的。

业务特点

瞬时用户量大

为了营造促销气氛,秒杀往往是定时在某个时间点开放购买。大家到点几乎同一时间打开页面抢购,瞬时并发访问量突增 10 倍,甚至 100 倍以上。

库存少

一般参与秒杀的商品库存都比较少,这导致了抢到的用户占少数,由于大家目标明确,没抢到大概率还会反复刷新页面,就如 12306 购票,不买到不罢休~

购买流程单一

抢购往往针对某一商品,购买流程相对简单。下单,减库存,支付。不存在购物车等。

技术难点

对现有业务的冲击

秒杀属于一种促销活动,网站同时进行的还有普通的购买服务,或其它的促销活动。不能因为秒杀活动出现问题连带其它业务也出现异常。

页面流量激增 & 服务高并发

秒杀活动开始前后,瞬间会有很多用户访问网站和商详页,造成网络带宽陡增,以及后台服务器压力增加。

不能超卖

抢购的商品都是预设好库存的,只有这么多。不能因为瞬间用户量大导致系统没控制住出现超卖情况。

黄牛捣乱

由于商品的稀缺性,利益相关,造就了黄牛产业链,甚至很多黄牛就是计算机高手。系统需要甄别哪些是普通抢购用户哪些是黄牛党。

优化方案

扩容

为应对高流量访问,当然最先想到的是扩容。增加服务器带宽,以及后台 WEB 层的计算能力。

页面静态化 & CDN

可以在活动开始前,将商详页信息静态化,比如:商品信息,SKU 信息是不会变的。甚至库存信息都不一定需要实时的,就像 12306。

页面静态化可以减少后台压力,再加上接入 CDN,就更加可以提升页面并发能力。

前端页面控制

在用户量很大的情况下,往往会出现下单失败的情况,用户肯定会刷新页面再次点击购买。这时前端可以控制,比如:下单后按钮变灰,限制 10 秒内只能提交一次,提示排队中让用户不可操作之类的。

专门的秒杀系统

购买流程中比较靠前的系统,如:商详、库存、下单,需要搭建专门的秒杀系统。与普通的购买服务分开。防止因秒杀流量激增影响其它服务。

使用内存缓存

大量的下单请求到达系统,导致大量的查库存、减库存动作,还是使用数据库的行级锁效率很低。可使用内存缓存,将商品数量和剩余库存存入 Redis 中,使用原子性的 INCR 可提高下单吞吐量。

限制异常请求

对于同一用户,限制接口请求频率。设置黑名单,IP 过滤等。

削峰 & 排队

可以引入排队机制,如:小米官网的抢购。用户点击购买后,需要页面不动一直等待排队。后台可以通过缓存或 MQ,来使下单过程平缓些。