业务背景

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

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

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

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

5. 老板要求万无一失。

业务场景

1. 用户只有在 APP 上登陆后，才能看见秒杀商品

2. 所有用户都能看到其他正常商品

存储架构设计

存储性能估算

注册和登陆都是已有功能

秒杀商品

2 件商品，读取量，在秒杀的那几秒钟，会有大量的读请求，假如当天 60%活跃用户，10%参加秒杀，100w*0.6*0.1=6wQPS，考虑到用户秒杀时会不断刷新，因此实际请求量会高于 6w

商品下单

秒杀商品一共 1012 个，订单最多生成 1012 个

支付

最多 1012 个

存储架构设计

1. 商品信息，订单信息，支付流水等数据，使用 MySQL 存储完全够用

2. 商品读取请求 6wQPS，使用 Redis 作为缓存，将商品放在三个集群中，每个集群放置一部分库存信息

计算架构

负载均衡

负载均衡使用现有架构即可

缓存设计

APP 缓存可以对秒杀商品使用静态页面，对同一 IP 进行限制，比如只能访问 5 次，扣减库存使用分布式缓存，库存为零时拒绝接下来的请求。

可扩展架构设计

服务已经使用微服务拆分，所以在这个基础上复用基础设施和一些业务系统，比如订单、用户和支付系统，增加秒杀系统，只服务秒杀商品

高可用架构设计

目前公司只有一个机房，不能因为秒杀活动就增加一个机房，因此使用主备和集群来增加可用性