毕业设计项目

设计电商秒杀系统

业务背景

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

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

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

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

4. 老板要求万无一失。

技术背景

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

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

3. 目前只有单机房。

业务基本场景

1. 在 App 和微信小程序宣传 618 秒杀活动，通过仅限 App 参与秒杀的方式，引导客户下载并登录 App。

2. 商城首页增加秒杀活动入口页面，列出秒杀活动商品，可以提前加入购物车。

3. 618 当天秒杀活动开始，点击按钮秒杀，下单并完成支付。

4. 秒杀商品库存清零后，秒杀按钮置灰，告知其他用户秒杀商品已抢完。

用户行为建模与性能估算

1. 假设电商平台 500 万注册用户，每条用户数据存储 1KB，则总共 5GB 用户数据。

2. 目前商城只有 200 个商品，每个商品信息需要存储 10MB，共 2GB。

3. 电商日活 100 万，每个用户每天登录、浏览商品、添加购物车记录 1K，登录及商品浏览记录主机保留一年，共 365G。

4. 通过前期活动宣传，618 当日有 300 万的用户登录 App，并有 50%的用户参与秒杀活动，秒杀用户有 150 万。

5. 假设参与秒杀的用户在活动前 1 小时内登录 APP 参与秒杀，假设每个用户浏览 10 个商品，每个用户平均往后台请求 20 次，则$QPS=150万\ast 20/3600=8333$，峰值 QPS 按 3 万进行估计。

6. 假设秒杀活动在 30 秒内结束，通过本地 APP 限流方式，过滤掉 90%的请求，则$TPS=150万\ast 0.1/30=5000$，峰值 TPS 按 2 万进行估计。

存储架构设计

电商平台数据存储容量不大，但用户点击查询商品信息的 QPS 较大，秒杀商品的 TPS 较大。用户注册信息、登录浏览记录、以及商品信息、订单信息采用 MySQL 主备架构存储。商品的页面展示、秒杀商品的库存需要用 Redis Cluster 进行缓存。

计算架构之负载均衡

TPS 和 QPS 的总峰值大概 5 万，采用两台 Nginx 进行负载均衡。

计算架构之缓存架构

秒杀页面的静态资源可以保存在 App 或者 Web 容器缓存内。库存及商品信息缓存在 Redis 集群中。

高可扩展架构设计

电商平台已经落地微服务架构，可以将秒杀拆分为独立的微服务。

高可用架构设计

目前只有单机房，可以先做同城双中心，先做灾备，再演进到双活。