1.背景

1.1 业务背景

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

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

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

4. 老板要求万无一失。

1.2.技术背景

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

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

3. 目前只有单机房

1.3 业务基本场景

1. 下载 app，只有下载 app 才能参加秒杀

2. 浏览秒杀商品

3. 想要参加秒杀必须要登录，如果已登录可以参与秒杀

4. 如果未登录，则需要用户注册或者登录

5. 活动未开始不能点击购买

6. 活动开始可以点击购买

7. 下单检查是否超过秒杀商品总数

8. 超过商品总数，显示秒杀结束

9. 秒杀成功后再付款

3.总结架构设计

1. 正常日活用户 100 万用户，大概有 60%~120%的用户会参与秒杀活动，所以架构按照百万用户级别参与秒杀设计，适应最大业务需求。

2. 客户端只有下载 App 才能参加秒杀活动，所以架构设计只考虑 App 的情况。

3. 秒杀活动不经常有，保持单机房不变。

4.存诸架构设计

4.1 存储架构估算

• 登录

正常日活用户 100 万，登录数据是每天 100 万

• 注册

百万注册用户信息，秒杀预估比正常多，那有 110 万的用户信息

• 浏览秒杀商品

100 万用户同时浏览两种商品，1000 个充电宝和 10 台 iPhone12。需要将数据保存在 redis，

• 下单

1000 个充电宝和 10 台 iPhone12，订单数量 1，由于只有 1000 个充电宝，和 10 台 iphone12,因而只有 1012 笔下单记录

4.2 存诸架构

• 秒杀开始时，为了支撑大量高并发的商品库存查询，用 Redis Cluster 支持。

• 商品库存扣减和订单操作数据量不大，仍然有 MySQL 支持

5.计算架构设计

1. 注册登录

TPS: 日活用户 100 万人，假定活动当天新增 10 倍用户，一共 1000 万用户，80%登录注册发生在 5 小时内，则 TPS=1000 万*0.8/5/3600=450

1. 热销商品

QPS:10 大类，每类 20 个商品，一共 200 个商品。当天一共 5 倍的人查看，每人查看 3 次，每次查看 5 个商品，且 80%的请求发生在 5 小时内，则 QPS=500 万*3*5*0.8/5/3600=340

1. 秒杀商品

QPS：1000 个充电宝，10 个 iphone，假定当天 5 倍人参与，共 500 万，每个商品每人点击请求 3 次，秒杀请求发生在 1 分钟内。则 TPS=500 万*2*3/60=50 万

1. 支付

TPS 热销商品：点击抢购后，进入支付界面，支付前查询商品剩余数量是否大于 1，支付后商品数量减 1，TPS 为 340。

TPS 秒杀商品：和上面逻辑一致，TPS 为 50 万。

5.1 负载均衡架构设计

初创公司，F5 价格过高，为满足峰值数百万的请求，使用 DNS 做作为一级负载均衡。nginx 为负载

5.2 缓存架构设计

1. App 缓存+web 容器缓存商品详情页+分布式缓存

2. 使用 APP 缓存和 WEB 缓存将大量静态页面保存起来，秒杀时静态页面从 APP 或 Web 获取，减轻后端压力。

3. 秒杀开始后，为支持大量库存查询请求，使用 redis 保存库存，分布式缓存使用 redis，为应对大流量，redis 采用 redis cluster 方式部署。