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

【业务背景】

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

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

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

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

4. 老板要求万无一失。

【技术背景】

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

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

3. 目前只有单机房。

【毕设要求】

1. 设计完整的架构，例如存储、负载均衡、缓存、高可用、可扩展等；

2. 大约 10 页以内的 PPT，每页 PPT 说明一项设计，包括架构设计和设计理由，无需详细解释备选方案。

【提示】

1. 分析考虑要全面，但并不意味着架构设计要面面俱到，如果分析后认为某些设计点可以不做，就在作业最后统一说明原因即可；

2. 如果没有思路，请对照模块 9 的 IM 案例；

3. 如果有的信息觉得不够全或者不够细，可以做出一定的假设，但不能天马行空，需要对照已有的业务背景和技术背景进行合理推断

1. 业务分析

1，日活用户大约 100W，可以推断用户量为千万级别。

2，老板要求万无一失，代表系统需要高可用。

3，秒杀系统可以使用 redis+lua 作为存储用来扣减库存。

4，存储方面采用 mysql，缓存采用 redis。

5，10 个品类不超过 20 个商品，也就是 200 个商品。

1. 秒杀活动的瞬间流量很高，需要用缓存和消息队列，降低后端压力。可以时候要你管 redis+lua 作存储。

2. 日活用户 100 万，在秒杀活动期间，至少会有 3~5 倍的用户参与，架构设计至少参照千万级别架构设计。

3. 老板要求万无一失，要考虑高可用。

4. 团队已经落地微服务，而秒杀活动的流量很高，所以在原有的 spring Cloud 基础上，单独开一些服务，专门做秒杀。

5. 创业型公司，技术人员不会太多，作为业务重点的秒杀活动，可用根据需求找 12 个人做后端，andorid3 个，ios3 个。

6. 
   

3. 业务基本场景

1. 活动未开始不能点击购买

2. 活动开始可以点击购买

3. 下单检查是否超过秒杀商品总数

4. 超过商品总数，显示秒杀结束

5. 秒杀成功后再付款

4. 总体架构思路

1. 正常日活用户 100 万用户，大概有 60%~120%的用户会参与秒杀活动，所以架构按照百万用户级别参与秒杀设计，适应最大业务需求。

2. 客户端只有下载 App 才能参加秒杀活动，所以架构设计只考虑 App 的情况。

3. 秒杀活动不经常有，保持单机房不变。

5. 存储架构设计

5.1 存储架构估算

• 1，日活用户 100W，假设每个用户每天晚上 8 点-12 点之间下单一次，那么每天就有 100W 数据，从数据量上来看，存储需要分库分表，读写分离。

  TPS:100W/4/3600=69.4。

  2，活动当天，推断用户数量增加，那么假设为平日的 3 倍，那么就有 300W 用户参与当天的 618 活动。

  TPS:100W/4/3600*3=208.33。

  3，秒杀商品只有 1000 个充电宝，10 台 iPhone 12，由于只有 APP 用户才能参与秒杀，所以并不是人人都会参与秒杀，故假定参与秒杀的人数为 1/3，那么就有 100W 人参与秒杀。

  4，另外由于是电商系统，有许多的商品图片等，可以采用图片服务器来单独存放商品图片。

  5，秒杀系统部分使用 redis+lua 作为库存部分。

5.2 存储架构设计

• 秒杀开始时，为了支撑大量高并发的商品库存查询，用 Redis Cluster 支持。

• 商品库存扣减和订单操作数据量不大，依旧用 MySQL 支持。

6. 计算架构设计

6.1 计算性能估算

• 登录

估计有 60~120 万用户登录，考虑到 50%用户可能会集中在秒杀时间前 1 个小时登录，登录的 TPS 值：

50 万/3600 ≈ 140

• 秒杀

估计有 60~120 万用户会在前 2 秒内参与秒杀，绝大部分是读请求。秒杀的 QPS 值：30 万~60 万

6.2 计算架构之负载均衡

• 考虑到 QPS 在 30 万~60 万，采用 LVS 作负载均衡设

6.3 计算架构之缓存架构

• 尽量把商品详情页的页面元素静态化，然后使用 CDN 或 App 把这些静态化的元素缓存起来。秒杀前大量请求可以直接由 CDN 或 App 缓存服务，不会到达服务器端，减轻服务器端压力。

• 秒杀活动开始，为了支撑大量高并发的库存查验请求，由 Redis 保存库存，扣减库存。yin'ci 分布式缓存也选用 Redis。

7. 高可用(Plan B)

秒杀系统在大流量的冲击下，容易出现意外情况，为了保证系统的高可用，要有相应的保护措施。

• 收到秒杀请求后并不是立即处理，而是放到消息队列，系统根据能力进行异步处理。

• 队列的大小根据秒杀商品数量或多一些定义。

• 相比较限流来说，排队的客户端体验要更好一些。