一、需求分析

【业务背景】

你作为一个电商创业公司的架构师，负责设计 6.18 大促秒杀系统的设计，你们的业务模式如下：

• 你们挑选选品各大电商平台上畅销和好评的商品进行销售，每个品类不超过 20 个商品，目前做了 10 个品类

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

• 正常的日活大约 100 万用户

• 老板要求万无一失

【技术背景】

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

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

• 目前只有单机房

【毕设要求】

• 设计完整的架构，例如存储、负载均衡、缓存、高可用、可扩展等

• 大约 10 页以内的 PPT，每页 PPT 说明一项设计，包括架构设计和设计理由，无需详细解释备选方案

【提示】

• 分析考虑要全面，但并不意味着架构设计要面面俱到，如果分析后认为某些设计点可以不做，就在作业最后统一说明原因即可

• 如果没有思路，请对照模块 9 的 IM 案例

• 如果有的信息觉得不够全或者不够细，可以做出一定的假设，但不能天马行空，需要对照已有的业务背景和技术背景进行合理推断

二、总体架构思路

【服务划分】将微服务划分为：会员服务，商品服务，库存服务，订单服务

【活跃预估】假设大促期间参与活动的日活为原来 3 倍，即 300 万日活

【可用性】老板要求万无一失，由于目前只有单机房，考虑使用同城双机房方式保证

【其他限制】必须登录才能参加秒杀活动

三、性能估算

【登录数据】

• 主要用户为 app 用户，由于 app 的特性，在活动日产生登录的数量大概率为新注册用户。假设新注册人数为日活的 5%，则大致为 15 万/日。考虑注册一般集中于开始秒杀的前一小时内

• QPS 分析：150000/24/60/60≈2

• 存储分析：150000*1k=150M

【商品数据】

• 预估秒杀峰值时，同时活跃的用户是 300 万，则

• QPS 分析：300 万

• 商品数据使用 redis 缓存，图片使用 oss

【订单数据】

• 由于秒杀一般都是一瞬间完成的

• QPS 分析：300 万

• 假设有 20%的用户抢 iPhone 12，80%的用户抢充电宝，则 iPhone 12 为 60 万 QPS 抢 10 台，充电宝为 240 万 QPS 抢 1000 台，中奖概率极低

• 为了降低系统负担，秒杀 iPhone 12 的场景中，使用哈希过滤掉 99%的请求后，剩余 1000QPS；秒杀充电宝的场景中，使用哈希过滤掉 95%的请求后，剩余 10 万 qps

四、存储架构设计

【MySQL 设计】

【Redis Cluster 设计】

五、计算架构设计

六、缓存设计

七、同城双活设计

八、大数据架构设计

不涉及大数据搜索，故无需考虑。