秒杀架构设计

架构设计

平时日活 100 万，

假设一半用户参与秒杀，秒杀用户数 50 万；

假设秒杀期间每人访问 10 次，则商品浏览次数 50 万*10=500 万

秒杀商品为 1000 个充电宝，10 台 iPhone 12 作为秒杀商品，假设每人每单限制购买一个商品，则总单量 1010 单，在客户端就丢弃大部分秒杀请求，这里假设 1 万个下单请求到达后端，

系统要保证万无一失，假设是能应对机房级别的灾难。

存储架构

• 登录注册：假设秒杀期间用户登录注册没有大幅变动，原有系统即可支持，不做额外考虑

• 商品：秒杀商品为 1000 个充电宝，10 台 iPhone 12 作为秒杀商品，秒杀商品很少，MySQL 存储商品数据，商品库存放在 redis 缓存中

• 下单：假设每人每单限制购买一个商品，则总单量 1010 单，MySQL 存储即可

商品、订单数据：

库存数据：

计算架构设计

• 登录注册：假设秒杀期间用户登录注册没有大幅变动，原有系统即可支持，不做额外考虑

• 商品：按上述预估，商品浏览次数为 500 万，所以要设计多级缓存架构，大部分请求可以通过 CDN 返回

• 下单：按上述预估，到后端的有 1 万条下单请求，生成的有效单量为 1010 条，假设秒杀 在 1 分钟内结束，下单 TPS=10000/60≈200

1、负载均衡

2、多级缓存

3、

限流：在 App UI 上进行秒杀请求限流；在接入端限制用户请求频率；同时允许服务器根据处理能力进行限流。

排队：引入队列，将秒杀请求进行异步处理。

降级：故障应急时降级其他相对非核心业务，如日志服务，或秒杀高峰期暂停退货请求等。

熔断：下游接口故障时，一定时期不再调用，防止链式效应。

可扩展架构设计

原系统已经是微服务架构，新增一个秒杀商品微服务、秒杀订单微服务

高可用结构设计

为了保证万无一失，可以新建一个机房，设计异地双活架构