模块九作业 - 设计电商秒杀系统

业务场景

一、秒杀业务

1、每个用户需先登录

2、用户导航到秒杀商品页面

3、秒杀时间到进行抢购

4、抢购成功进行支付

二、正常业务

1、由于 6.18 秒杀活动，正常业务流量会增加，热门商品和其他商品会随之增加购买流量，按平时的 5 倍进行系统评估和扩容机制来支撑，假设正常业务足以支撑 5 倍流量。 —— 不做分析

用户量估算

业务背景日活 100 万

1、登录：秒杀活动开始前，用户已经提前登录——不考虑

2、秒杀商品页：用户一般都会频繁刷新页面，等待秒杀时间到——CDN/Nginx 缓存商品静态页面

3、抢购：用户一般会在抢购失败后，继续点击抢购——前端限制请求

4、支付：由于秒杀商品数量 1000 个充电宝 + 10 个 IPhone，支付请求量低——不考虑

5、发货：秒杀业务由于商品增加少，不影响发货——不考虑

存储性能估算

抢购记录存储：假设没条记录 64 字节，则需要 640M（1 千万 * 64 / 1000 / 1000）

计算性能估算

TPS：由于秒杀基本就集中在前 1 秒时间内，假设 10%的人参与抢购， 所以 TPS = 10 万

QPS：10 万

指标汇总

高性能——需要，TPS 10 万，QPS 10 万

高可用——需要，秒杀期间系统不能出问题，保证商品不超卖，不少卖

扩展性——不需要，秒杀系统业务单一，使用后就短时内不会再用

安全 ——需要，防止褥羊毛

成本 ——不考虑，满足指标前提下以节约成本为目标。

存储容量——不考虑，容量规划 1G 就够了

存储写性能——需要，TPS 10 万

存储读性能——需要，TPS 10 万

设计关键点

1、前端限制抢购只能一次请求，请求接入层限流

2、秒杀商品页静态资源缓存

3、多级负载均衡，要支持 10 万请求

4、异步支付

5、数据强一致性

存储架构设计

说明：秒杀系统存储容量小，一台 Mysql 可以支撑，秒杀抢购记录写入 TPS 10 万，可通过异步后台慢慢写入；Redis 存储秒杀商品数量，开启每次请求都刷盘机制，保证数量正确性；秒杀结果后把 Redis 的商品数量同步与 Mysql；

缓存架构设计

说明：Web 容器选择 Nginx，可缓存商品页静态资源；另 APP 终端可缓存静态资源；分布式缓存选择 Redis，可缓存秒杀商品梳理。

负载均衡架构设计

高可用存储架构设计

秒杀总体架构