业务背景

你作为一个电商创业公司的架构师，负责设计 6.18 大促秒杀系统的设计，你们的业务模式如下：

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

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

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

4. 老板要求万无一失。

技术背景

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

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

3. 目前只有单机房。

业务基本场景

登录 -->秒杀 -->下单 --> 支付　

架构设计

存储

性能估计

【登录】

日活百万，登录读取用户信息，秒杀时假设都参加，假设为秒杀前十分钟登录，则登录每分钟十万请求，则登录 qps 为 1700QPS 左右

【秒杀】

假设日活都参加秒杀，假设大家都在 10s 内进行参与秒杀，则 10 万 qps

同时，假设进入秒杀页面的都点一下秒杀，则秒杀的 tps 为 10 万 tps

【下单】与【支付】

由于商品数量有限，能成功到达下单和支付的最多也就 1000tps

架构设计

说明：登录的微服务肯定是已经有了，但为了秒杀场景，用户会出现集中登录情况，所以改进登录的存储架构，增加为 mysql 主从适应登录

说明 2：redis 存储秒杀的商品信息用于暂时，redis 并提供库存的查询和库存的扣除操作

计算

【登录】

日活百万，登录读取用户信息，秒杀时假设都参加，假设为秒杀前十分钟登录，则登录每分钟十万请求，则登录 qps 为 1700QPS 左右

【秒杀】

假设日活都参加秒杀，假设大家都在 10s 内进行参与秒杀，则 10 万 qps

同时，假设进入秒杀页面的都点一下秒杀，则秒杀的 tps 为 10 万 tps

【下单】与【支付】

由于商品数量有限，能成功到达下单和支付的最多也就 1000tps

负载均衡架构

说明：因为秒杀的 tps 达到 10 万，所以保险起见使用 LVS 作为负载均衡，同时，在前端限制用户一段事件只能点击一次秒杀按钮，避免 tps 无谓的增加压垮机器。

缓存架构

说明：缓存主要是缓存静态资源，秒杀商品的基本信息和图片，避免每次都需要访问数据库进行获取相应的商品信息，并使用提前加载的功能，在秒杀之前就同步好 web 容器缓存和分布式缓存，让商品基本信息，在秒杀时已经准备好了，不需要进行访问数据库和文件存储。

可扩展设计

说明：维持其余微服务不变，增加秒杀微服务，专门用于处理秒杀场景

高可用设计

接口高可用

说明：使用漏桶进行防范进行秒杀流量瞬间太高，丢弃过多的请求影响极小，因为本来靠后的人也没什么机会抢到商品。

双活设计

由于本身是单机房，且计算架构本身也是高可用，redis 也是高可用，负载均衡也有双机故障转移，所以为了单单两个商品的秒杀，不需要进行双机房的配置进行双活，代价过大。放弃双机房

完整流程