1、业务背景

6.18 大促，业务模式如下：

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

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

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

• 老板要求万无一失

2、技术背景

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

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

目前只有单机房

3. 业务基本场景

登录注册----->商品列表/详情----->抢商品----->付款

• 使用 APP 登录的用户才有秒杀商品的入口显示

• 商品详情页面，会有一个抢购按钮，秒杀商品默认只能购买一件

• 时间不到，前端按钮置灰，后端也会做校验

• 用户提交订单，对应的库存减 1，提交订单的时候会进行库存校验

• 商品库存为 0 的时候，秒杀结束

4.计算、存储性能估算

日活 100w 用户，是注册用户的 40%，这注册用户有 250w，假设用户每天的高峰期上午 9 点到 12 点，下午 1 点到 5 点，晚上 8 点到 10 点，集中在这 10 小时，占日活的 80%，则平均 QPS：1000w*80%/10/3600=222/s

，6.18 大促在没有秒杀的情况下，流量是平时的 5 倍左右，QPS 约为 1000

秒杀场景另算

注册：用户有 250w

登录：日活 100w，需要查询用户信息，每天 100w 的 QPS，按 10%的订单转换率，每天有 10w 的订单数据，6.18 大促，是平时的 5 倍，所以 6.18 有 50w 的订单数据，每年约有 4000w 的订单数据

商品详情：假设平时每个用户查看 5 个商品，6.18 是平时的 5 倍，则每天商品详情的 QPS 是 100w*5*5=2500w，每秒约为：300QPS。但是大部分的商品详情集中在秒杀阶段，所以以抢商品的分析为准

抢商品：假设秒杀商品的用户是活跃用户的 50%，则有 100w*50%=50w 的用户秒杀商品，商品详情 80%集中在倒计时最后五分钟，则峰值 QPS = 50w *80%/5/60=1333/s，方便计算 QPS 约为：1500/s

库存：1010，则 TPS：1010，假设每请求商品详情都会去读库存，则库存的 QPS 约为 1500*5=7500/s

5.存储架构设计

订单表数据做分库分表

6.计算架构设计

6.1.负载均衡架构

6.2.缓存架构

6.3.抢购的排队架构

7.微服务拆分

这里需要注意，商品秒杀是一次性的，但是这类活动时不时的会有，所以需要单独拆出来一个秒杀服务用于专门的促销活动，秒杀服务不可用也不影响整个电商系统，具体拆出来多少个微服务，需要符合 3 个火枪手原则。

8.高可用架构设计

老板要求万无一失，所以需要做好高可用