毕业设计：设计秒杀电商系统

1. 业务基本场景

• 系统（
  APP
   和微信小程序）首页展示秒杀活动，非秒杀时间段秒杀按钮灰显，用户即使不注册登录也是可以浏览商品列表、商品详情的；

• 微信小程序只能看秒杀活动，但是不能参与秒杀，仅能通过
  APP
   客户端参与秒杀；

• 秒杀一般是定时上架，用户可以看到该商品，但是无法点击“立即购买”的按钮，秒杀开始前用户会快速刷新商品页面，访问量很大，在秒杀开始的时候抢先进入下单页面；

• 此次秒杀限量限价不限时，尽可能的为商城引流；而秒杀开始前，商城需要有一系列的活动预热；用户必须先注册登录才可以参与秒杀；

• 秒杀时，只有用户提交的第一个订单发送给网站的订单子系统；

• 每个用户要确保只能秒杀一件商品，只有第一个提交的订单发送给网站的订单子系统；

• 秒杀一般是定时上架，且不能出现“超卖”的问题；

• 秒杀活动是一种营销手段，不能影响商城的日常应用。

2. 存储架构设计

2.1 存储性能估算

2.1.1 注册登录

日活大约 100 万用户，假设日活占用户总数的 20%，则实际用户约为 500 万，假设秒杀活动吸引 10 万新用户注册。假设秒杀时，共有约80%的用户（即：400万用户）登录访问系统，需要存储400万用户的登录数据。

2.1.2 商品信息

• 存储的商品信息共有
  10个品类 * 最多的20个 = 200条
  数据

• 参与秒杀的用户会快速刷新商品页面，假设每个用户刷新 5 次，则商品信息的请求次数是 400 万*5=2000 万。秒杀的用户快速刷新商品页面主要集中在活动开始前的1小时，则这段时间查询商品信息的
  QPS
   ：
  400W * 5 / (60 * 60) = 5555

2.1.3 秒杀

秒杀商品是 1000 个充电宝、10 台 iPhone 12，秒杀有效订单就是 1010。假设当天的用户平均有 1 条订单，则当天的订单数据有 400 万 条，每个用户查询订单 2 次，则有 800 万 条订单查询请求。

2.1.4 订单

假设秒杀活动当天 400W 用户当天平均有 1 条订单且集中在秒杀的 1 小时内，则生成订单的 

TPS = 400w/60/60 = 1111

；要存储的订单数据是 400W 条记录，当天用户平均查询订单 2 次，800W条请求。

2.2 存储架构设计

其中：

• MySQL
   数据存储500万用户信息和400万用户登录信息

• MySQL
   数据库维护200条商品信息的关系数据库

• MySQL
   数据库存储400W条数据

• Redis
   缓存数据库存储商品的请求信息2000万，订单请求次数400万

3. 计算架构设计

3.1 计算性能评估

3.1.1 注册

假设秒杀活动吸引 10 万新用户注册。

3.1.2 登录

活动当日预估有400 万用户登录，并经过活动预热，登录注册的时间集中在秒杀前 30分钟内，则注册登录 TPS = 410W/30/60= 2278。

3.1.3 商品信息

参与秒杀的用户会快速刷新商品页面，假设每个用户刷新 10 次，且集中在秒杀前 1 小时，则查看商品信息的 QPS 是

 400 万*10/60*60 = 11111

。

3.1.4 秒杀

由于秒杀是限量，假设商品在 10S 内秒杀完成，400 万的用户 10S 每个用户平均请求 5 次，则秒杀请求 TPS = 400 W *5/10 = 200W。

3.1.5 订单

• 秒杀有效订单 1010，假设这些订单都是在 5S 内生成，则生成秒杀订单 TPS = 1010/5 = 202。

• 按照之前的假设，400W 用户当天平均有 1 条订单且集中在秒杀的 1 小时内，则生成订单的 TPS = 400w/60/60 = 1111；

• 存储的订单数据是 400W 条记录，当天用户平均查询订单 2 次，查询订单请求量是 800W；假设查询时间集中在秒杀后 2 小时，查询订单 TPS = 800W/60/60/2 = 1111。

3.2 计算架构之负载均衡设计

3.2.1 业务特性分析

秒杀请求 TPS = 400 W *5/10 = 200W。，因此需要采用多级负载均衡架构，覆盖 DNS->Nginx->网关的多级负载均衡；

3.2.2 架构设计

秒杀请求依赖登录状态，登录状态一般都是保存在分布式缓存中的，因此发送秒杀请求发送给任意服务器都可以，这里选择“轮询”或者“随机”算法。

3.3 计算架构之缓存架构设计

3.3.1 下载APP

假设参加秒杀活动的用户中有 10%没有下载过 App(大小为 50MB)，且集中在秒杀开始前 1 小时下载，则需要的带宽为 40 万*50MB/3600s=5500MB/s，用 CDN 缓存。

3.3.2 业务特性分析

查看商品信息的请求量是 4000W ，查询订单请求量是 800W，用多级负载均衡架构。

3.3.3 架构设计

游客都可以直接查看商品信息，因此将请求发送给任意服务器都可以，这里选择“轮询”或者“随机”算法。

4. 高可用架构设计

• 秒杀活动非常态，是一种营销手段，持续时间短，但是会产生比平时大数十倍的页面访问流量和下单流量，如果将秒杀活动和商城的普通应用部署在一起，可能会对日常业务造成冲击，为了提高可用性，可以将秒杀系统独立部署，甚至使用独立域名，使其完全隔离。

• 由于秒杀请求的 TPS 非常大，可以使用排队架构，收到请求后并不立即处理，而是将请求放入队列，系统根据能力异步处理。

4.1 秒杀排队架构

4.1.1 业务特性分析

秒杀请求 TPS = 200W ，收到请求后并不同步处理，而是将请求放入队列，系统根据能力异步处理。

4.1.2 架构设计

使用排队服务器，技术本质是：请求缓存+ 同步改异步+ 请求端轮询 。

5. 可扩展架构设计

技术团队以 Java 为主，已经落地了微服务架构，可以选择 Spring Cloud 作为微服务基础框架。

6. 演进

第一期按上述功能实现（商品类型、数量、到达排队模块的数量按商品数量 5 倍算）；

第二期运营系统，配置商品类型、数量，动态设置通过客户端的到达排队模块的请求量/商品数量的比例。