1.业务背景

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

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

3、正常的日活大约 100 万用户

4、老板要求万无一失

2.技术背景

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

2、主要渠道是自有的 APP(包括 IOS 和 Android)和微信小程序，为了促进用户转化为 APP 用户，只有下载 App 才能参加秒杀活动

3、目前只有单机房

3.存储架构设计

存储性能估算

【注册】

用户的注册信息

【登陆】

日活为 100 万用户，假设有 40%的用户参与秒杀，档次秒杀活动登陆时读取用户信息有 40 万 QPS

【秒杀商品页面】

进入秒杀页面，假设用户会提前 5 分钟开始进入页面，即每秒大约 1333QPS，提前生成单独的静态页面，用 CDN 进行缓存

【秒杀】

秒杀请求，40 万用户参与，大约有 40 万的 TPS，只会有 1010 个用户可以秒杀成功到商品，产生 1010 条订单记录

活动商品库存采用 Redis Cluster 提前预热缓存，1010 个商品分配到两个切片上，采用 lua 进行库存校验和扣减库存，库存扣减成功即秒杀成功

【付款】

一共只有 1010 个用户可以秒杀成功进行付款，即每 10 秒只有 101TPS

存储架构设计

4.计算架构设计

计算性能估算

【注册】

每天新增的用户量基本不到 1 万，可以忽略不计

【登陆】

日活为 100 万用户，假设有 40%的用户参与秒杀，且基本集中在 10 分钟的秒杀活动时间，登陆的 QPS：40 万/ 600 = 666/s

【秒杀页面】

进入秒杀页面，假设用户会提前 5 分钟开始进入页面，即每秒大约 1333QPS，提前生成单独的静态页面，用 CDN 进行缓存

【秒杀】

有 40 万的用户参与秒杀，秒杀请求的 TPS 为 40 万

秒杀成功，只会有 1010 个秒杀记录，假设 1 秒完成，TPS 也才 1010，忽略不计

【付款】

只有 1010 个订单记录，TPS 为 1010，忽略不计

计算架构负载均衡

秒杀时，由 CDN 选取 n 个请求，假设共计 40 万请求流到秒杀系统，Nginx 可以满足

计算架构之缓存架构

计算架构之高可用

【限流】

在静态页面或者在客户端，限制频繁用户刷新数据，增加滑动验证码之类的功能错开请求

CDN 对同一个 IP 地址 1 秒内只能访问一次

利用漏洞算法进行服务器的 2W 合法限流

5.可扩展架构