需求背景

1. 本次 6.18 秒杀选择了 1000 个充电宝，10 台 iPhone 12 作为秒杀商品；

2. 正常的日活大约 100 万用户；

3. 老板要求万无一失。

技术背景

1. 技术团队以 Java 为主，已经落地了微服务架构；

2. 主要渠道是自有的 App（包括 iOS 和 Android）和微信小程序，为了促进用户转化为 App 用户，只有下载 App 才能参加秒杀活动；

3. 目前只有单机房。

需求计算

原有系统： 1,000,000 用户 / 6 小时(假设 1800-2400 是高峰) ~= 50 qps,远小于资料库的 1000qps, 假设整个系统的 qps 爲 1000 qps

DAU: 1,000,000 秒杀 20s 内 1,000,000 *2(增加因秒杀活动而来的用户) => 100,000 qps => 远大于系统能力 => 需要限流

架构设计

限流设计

• 前端限流:

• 选项 1: 用户需预约秒杀活动, 根据人数决定放行比例, 目标后端平均 10,000 qps

• 选项 2: 以 1/10 的机率放行, 后端平均 10,000 qps

• 加上验证码, 避免机器人与脚本

• 后端限流消息队列: 秒杀活动同时也要兼顾正常营运, 秒杀下单后利用消息队列转往订单服务与付款服务, 避免瞬间高流量导致其他服务崩溃

计算高可用

前端限流后 10,000 qps,理论上一台 Redis 可以处理, 保险起见, 採取主从複製, 读写分离一主二从 + sentinel 集群

储存高可用

使用现有微服务

warm-up

• 将秒杀商品资讯放入 CDN

• 事先将库存秒杀商品资料载入到 Redis 中

架构