场景

秒杀，是互联网中比较常见的一种高并发场景，大体可以分为：限时抢购与限量抢购。

分析



上图是一个最简单的请求模型。

假如PM提出一次秒杀活动，有N件商品，在10分钟之内限量销售，每天X场抢购活动，每场持续Y小时。

1. 安全性，确定请求的是合法用户。

2. 库存每次售卖都要减库存。

3. 最小库存数不能为负数。

4. 一件商品不能卖2次。



设计

• 对于请求商品页面，提前静态化。

提前生成静态页面，放入CDN等静态资源服务器



• 提前准备好扩容资源。

现在基本都是基于云的部署，但是像618、双11、跨年，记得提前预备好资源（其他公司也要搞活动，资源很抢手的）。



• 前端做好时钟控制按钮是否有效。

攻防对战的最初级交锋，就是使用前端按钮置灰能力。这能过滤掉大部分无效请求哦。



• 能在越前面快速返回越好

活动未开始，业务层针对活动状态标识，做好快速返回（有些人会直接模拟请求，绕过前端置灰能力）。

活动结束后，快速返回。

在能做过滤的最前的位置，做好黑名单。



• 资源尽量隔离，有Plat B。

做好资源的限流、降级、失败方案。

隔离好正常业务与秒杀业务之间的服务，秒杀挂了不能影响线上其他服务。



• 业务层与数据层解耦

解耦才能通过中间缓存提速啦。



安全性

单用户控制时间窗口内的访问频率

1. 验证码

2. IP限制

3. 隐藏入口

羊毛党、脚本党

1. 转入黑洞服务

2. IP限制

3. 验证码

高性能

不止秒杀系统，其实是有的系统架构设计都需要考虑「分解压力」，在互联网项目中，大流量峰值不少见，这些流量理论上来说最终都会落到一个地方，并且最终会有一个有状态的最终节点，往往是性能瓶颈。



所以很多高性能系统，考验的就是如何分解压力避免请求层层传递或者怎么进行纵向、横向扩展。

使用Redis缓存进行库存增减

基于Redis做库存增减，使用任务对DB->Redis的更新。

Redis分布式锁的实现（这里是个大话题...）

维护秒杀结束标识

所有秒杀相关接口，都加上秒杀活动是否结束标识判断，如果结束直接返回，包括轮询拉取的接口。

控制请求队列长度

也算是对系统的一种限流保护策略，是从请求堆积量来衡量。

特殊方案（产品协调）

1. 如果产品可以的话，使用消息队列异步下单，削峰填谷。

2. lua + nginx 或 lua + redis 进行流量过滤。

兜底方案

降级

当系统的容量达到一定程度时，限制或者关闭系统的某些非核心功能，从而把有限的资源保留给更核心的业务。

限流

当系统容量达到瓶颈时，我们需要通过限制一部分流量来保护系统，并做到既可以人工执行开关，也支持自动化保护的措施。

拒绝服务

服务负载达到极限时，进行拒绝服务操作，保护服务正常恢复。