秒杀基本场景

• 注册、登录

• 查看秒杀商品

• 尚未开始

• 可秒杀（库存数量）

• 秒杀结束

• 秒杀下单

• 狼多肉少

• 订单支付

• 回退库存（支付失败时）

难点

• 秒杀限流

• 客户端限流

• 服务端限流

• ID 限流

• IP 限流

• 库存限制

• 秒杀扣库存

• 扣库存不能等到支付完成。

• 下单时扣库存，线程内，先扣库存后下单。

• 回退库存

• 支付失败时回退库存

• 支付超时

• 取消支付

• 秒杀微服务

• 秒杀类商品详情的动态数据，从秒杀微服务获取

• 秒杀类商品的下单，插入秒杀判定步骤，由 App 端和秒杀微服务负责

• 秒杀判定通过，App 端走正常的订单下单流程

• 支付失败时在秒杀微服务内回退库存

性能估算

日常

• 日活 100 万用户

• 200 个商品

商品动态数据请求

假设每日活用户每天浏览 10 件次商品

• 每日总计商品浏览 100 万 * 10 件次 = 1000 万件次

• 每秒平均商品浏览 1000 万件次 / 8.64 万秒 = 116 件次/秒

下单请求

• 每日下单 10 万

• 每秒平均下单 = 10 万 / 8.64 万秒 = 1.16

由于峰值往往是均值的几十倍，假设现有订单微服务能够承载 每秒峰值下单 100。

大促秒杀

假设浏览集中在秒杀开始前后各 5 分钟内。

秒杀商品动态数据请求

• 100 万秒杀参与者，人均载入秒杀商品动态数据 10 次

• 每秒 1000 万 / 60*10 秒 = 1.67 万次

秒杀请求

客户端百倍限流

• 100 万秒杀参与者，限流掉 99%，只剩 1 万参与者向服务器发起秒杀请求

下单请求

秒杀微服务判定为秒杀成功的大约只有 1010 单，订单创建排队延后。

• 已有订单微服务可以承载 每秒峰值下单 100

• 大约 1010 / 100 = 10 秒内完成所有订单创建

架构设计

存储架构设计

存储性能估算

• 存储 100 万秒杀参与者的 ID，IP

• IP 4 字节

• 用户 ID 8 字节

• 100 万 * 12 字节 = 12 MB

• 如果进行了客户端百倍限流，1 万 * 12 字节 = 0.12 MB

• 存储 1010 个秒杀成功的用户 ID，订单 ID

• 用户 ID 8 字节

• 订单 ID 12 字节

• 1010 * 20 字节 = 20 KB

如果不进行客户端百倍限流，虽然存储容量需求很小，但考虑到访问的短时密集性，秒杀系统需要使用独立的 Redis Cluster 对 Redis 访问进行分流。

计算架构设计

负载均衡

秒杀系统并不冲击现有的负载均衡，沿用现有设计即可。

但秒杀服务内，如果不进行客户端百倍限流，考虑到访问的短时密集性，秒杀系统需要使用对访问进行分流。

客户端百倍限流

客户端限流就是在客户端进行极端的负载均衡，根据特定算法，不向服务器发起请求就直接判定某些秒杀失败。如果本地阻截 99% 的秒杀请求，就实现了百倍限流。

缓存

原有的多级缓存

• 本地缓存（App 内缓存）

• CDN 缓存

• 分布式缓存

秒杀的静态资源继续使用原有的多级缓存

• 本地缓存（App 内缓存）

• CDN 缓存

秒杀的库存数量

• 应用内缓存

要提前进行缓存预热。

其它

可扩展方面无需额外改进，加入秒杀前已经使用了微服务。

高可用方面可以进行同城双中心的演化，但考虑到秒杀系统对整个系统的影响微乎其微，至少不会因为加入秒杀系统而进行同城双中心。