架构实战营模块九作业

设计电商秒杀系统

需求分析

需求背景如下：

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

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

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

4. 老板要求万无一失。

【技术背景】

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

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

3. 目前只有单机房。

分析：

秒杀的商品是 1000 个充电宝，10 台 iPhone，同时还有其他商品要进行销售。功能保障优先级：登录>秒杀>其他商品的销售。登录之后才能购买商品，所以登录最重要，秒杀活动是重点活动，所以秒杀在其次，其他商品也是需要保障的。

日活 100 万，在秒杀期间日活用户量应该会增长，预估应该在 150 万到 200 万之间。电商应用不是聊天应用那样的高频使用应用，日活 100 万，注册用户应该有千万级别，但是电商业务的大部分流量在浏览商品，下单操作对比浏览商品的操作不会有那么大，当前需求里的存储架构、可扩展架构、高可用架构、大数据架构设计应该参考百万用户架构设计，计算架构应该参考千万用户架构设计。

已经落地了微服务架构，这次秒杀活动应该是第一次做，所以这次可以考虑进行微服务拆分，将秒杀业务独立出来。

老板要求万无一失，所以需要考虑高可用架构，目前只有单机房，要保障秒杀活动进行过程中万无一失，要进行改造，做同城双活。

性能估算

【登录】

假设秒杀活动当天日活达到 200 万，登录操作在活动前两小时，平均 qps=200 万/7200=300

【浏览商品】

日活 200 万，假设秒杀之前都在浏览商品，qps=200 万

【下单】

秒杀商品 1000 个充电宝，10 台 iPhone，假设一秒抢光，tps=1010。普通商品的下单的量可以忽略，假设有 200 万用户，下单率 1%，如果集中在活动开始后的一小时内，tps=200 万*1%/3600=5。

负载均衡

qps 峰值能到 200 万，注册用户量到千万级，老板要求万无一失，可以使用 F5，如果老板觉得 F5 成本太高，可以用多台 LVS 替代。

缓存

缓存使用四级缓存即可，商品的图片、视频、详细介绍文字等静态信息使用 CDN 缓存，商品元数据加载到分布式缓存。

存储架构设计

商品信息分布式缓存

商品数据使用 redis cluster 存储。

存储高可用

大部分 qps 是浏览商品，商品信息使用缓存来存储，请求不会到 Mysql。tps 是下单产生的，会触达 Mysql，普通商品的不会特别高，秒杀商品的库存 tps 请求 redis，库存清零之后同步给 Mysql，所以 Mysql 主备就行。

要求万无一失所以使用 Redis sentiel 缓存库存数据。下单减库存使用 redis 分布式锁实现。

高可用架构设计

使用同城双活，老板要求万无一失，为防止秒杀进行过程中出现问题，还是需要做双活，如果只是灾备方案没法如果秒杀过程中出问题，没法保障服务可用，同城双活实现简单，成本低一些，当前用户量在一千万左右，日活最多 200 万，还暂时用不到异地双活。

微服务拆分

商品服务是通用服务，支撑所有商品的查询。秒杀服务专门为秒杀活动建立，秒杀商品库存计数缓存 redis 和库存信息同步到 mysql 库存表都包括在秒杀服务中。

大数据架构

商品数量还不多，目前还不涉及到推荐场景，只有数据分析场景，使用 clickhouse 即可。