业务背景

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

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

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

4. 老板要求万无一失。 

技术背景

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

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

3. 目前只有单机房。

场景分析

1、查看商品详情页

用户可以查看商品信息，秒杀时间未到，用户无法”秒杀”按钮。

2、“秒杀”处理

用户发起秒杀请求后，后台查询库存，如果库存不足则返回秒杀失败，如果库存够，则扣减库存，并且创建支付单。

3、支付

用户需要在规定时间内完成支付，如果预期未支付，则关闭该笔交易，并释放库存。

性能预估

1、热销商品详情

200 个热销产品，假设每个商品 5w 人关注，按每人每分钟 5 次访问计算，按 cdn 可以抵挡 90%的请求计算，下单请求按 10%计算

热销商品 Qps = 200 * 5w * 5 次 / 60 秒 * (1-90%) = 8w/s

热销商品 tps = 8w * 10% = 1w/s

2、秒杀商品详情

假设 1000 个充电宝和 10 台 iphone 在同一时间开启秒杀活动，假设 20w 用户参与秒杀商品，在秒杀开始前 5 分钟频繁请求商品详情，按平均每个用户每分钟请求 50 次来预估，cdn 抵挡 90%请求计算

秒杀前 5 分钟商品详情 qps = 20w * 50 次 / 60 秒 * (1-90%) = 2w

3、秒杀处理

假设 20w 人在秒杀活动开启后，10 秒内有 20w 请求，假设

秒杀处理 qps/tps = 20w /10 秒 = 2w

4、支付

支付的请求压力比较小，这里不考虑。

架构设计

1、存储架构设计

数据库采用 mysq 一主多从架构，分布式缓存采用 redis cluster

2、负载均衡架构

根据之前的预估 Tps+qps 大约 15w 左右，考虑到后续业务增长到千万规模，所以采用 4 级负载均衡架构。

3、缓存架构

4、计算架构设计

由于已经落地微服务架构，需要对秒杀服务进行系统拆分，实现服务和存储的隔离资源，以保证秒杀场景下高 qps/tps 不影响其他服务。

5、高可用架构设计

后续需要往千万级架构演进，考虑到当前系统规模只有百万，所以这里采用同城双中心的灾备架构。一方面可以有效控制成本，另一方面可以应对灾难。

6、大数据架构设计

hadoop+spark 架构已经比较成熟，可以直接采用该架构方案