业务背景

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

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

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

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

4. 老板要求万无一失

技术背景

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

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

3. 目前只有单机房

性能分析

• 正常日活是 100 万，秒杀时假设人数是平时的 2 到 3 倍，那么架构设计需按百万级别来设计，预计参与的人用户数为 300 万

• 用户需要提前登录，假设全在秒杀前 30 分钟内登录，则 QPS=300 万/180=1666/s

• 秒杀开始，假设秒杀请求在 30 秒内完成，平均每个用户点击请求 5 下，则 TPS=300 万*5/30=50 万/s

存储架构设计

数据分析：

• 库存数据，频繁读写，对应秒杀场景，单库无法支撑写请求时，可通过库存拆分的方式分担写压力

• 商品信息相对固定，读多写少，可以用读写分离，提升性能

• 订单及支付数据，因为秒杀的商品数较少，并不会增加订单数量，所以并不要特别考虑

根据上面分析，所以存储系统设计方案为：

• 商品信息、订单、支付账单，可先采用 MySQL 主从架构

• 商品详情页动静资源分离，静态资源通过引入 CDN 存储进行加速

• 用户信息、库存信息缓存到 Redis, redis 单机 TPS 为 5~10 万， 而在秒杀时有高并发的写，TPS 为 50 万/s，采用多机的 Cluster 架构

计算架构设计

负载均衡设计

采用多级 LVS 负载均衡

负载均衡

缓存设计

• 采用 app 缓存+web 容器缓存+分布式缓存三级缓存

• APP 端缓存+web 容器缓存，可缓存绝大部分静态资源，减少后端压力

• 分布式缓存，缓存库存，用户，商品信息

缓存

高可用设计

对于秒杀请求，采用限流策略：

1. APP 接入端限流：通过答题器降低接入请求，防止用户高频请求

2. 网关入口限流：业务规则过滤，检查库存

3. 秒杀任务排队：采用漏桶限流，将最后的合法秒杀请求放到限流桶队列，队列满则丢弃

目前情况是只有一个机房，且老板要求确保秒杀万无一失，可以优先购买云服务，将数据上传到异地云服务上。如果不购买云服务，可自建同城双活，不需要异地多活，如果距离过远，会影响秒杀延迟。

同城双活

可扩展架构设计（微服务拆分）

微服务拆分