设计电商秒杀系统

【业务背景】

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

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

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

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

4.老板要求万无一失。

【技术背景】

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

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

3.目前只有单机房。

【毕设要求】

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

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

【提示】

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

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

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

1.业务背景

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

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

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

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

4.老板要求万无一失。

2.技术背景

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

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

3.目前只有单机房。

3.业务基本场景

1.使用手机号注册，每个手机号，只能注册一个账号；

2.账号要实名认证，未认证账号，不能参与秒杀；

3.一般商品购买流程，先减库存（下单），后付款，有待支付订单有效期；

4.秒杀商品流程，和一般商品购买流程一致，入口在活动时间点，才开启；

5.秒杀商品，每人限购一件；

4.总体架构思路

1. 正常的日活大约 100 万用户，作为创业公司，日活比例假设高一些，占比 50%。则总用户有 200 万。活动期间，可能有新增 30-50 万。所以按照百万用户级别，进行秒杀设计，适应最大业务需求。

2. 基于现有微服务架构，可以快速落地，且方便拓展；

3. 用户接近 600 万，开始考虑千万级别架构设计。

4. 秒杀场景，最重要的是库存管理，和用户体验。

5.存储架构设计

百万用户存储性能估算

注册：

百万用户注册信息。

登录：

正常日活用户 100 万，秒杀活动，假设是两倍，登录数据是 200 万。

浏览商品：

10 个品类，每个品类不超过 20 个商品；

两个秒杀商品；

下单：

假设每天，每十个活跃用户下单 1 单，日单量为 10 万单

秒杀库存为：1010 个

支付：

和下单量数量级类似

存储架构设计

6.计算架构设计

百万用户规模计算性能估算

注册：

估计短期新增注册用户每日 10 万，可以忽略。

登录：

因为活动使用的是 app，大部分都是提前登录好的。假设需要登录的 50 万用户，集中在秒杀开始前 1 小时，登录 TPS 均值：500000/3600 = 139。

浏览商品：

普通商品

10 个品类，每个品类不超过 20 个商品；

每次访问，需要更新商品库存信息，通过 redis 获取（redis 商品信息，每秒更新一次）

日活 100 万用户，每次看 50 个商品，80%集中在早中晚睡前 4 小时，则 QPS 计算为：1000000*50*0.8/(4*3600)=2778 QPS

两个秒杀商品；

使用 APP，提前缓存商品基础信息。假设 200 万参与秒杀，其中 50 万，是第一次查看秒杀商品，时间集中在秒杀前 1 小时，则 QPS 均值：500000/3600 = 139。

下单：

假设每天，每十个活跃用户下单 1 单，日单量为 10 万单

80%集中在早中晚睡前 4 小时，则 TPS 计算为：100000*50*0.8/(4*3600)=278 QPS

秒杀库存为：1010 个

秒杀共两个品类，1010 个商品，假设秒杀在 10s 内完成

假设有 200 万用户参与了秒杀，每个人发起了 2 次下单请求(APP 控制)，在 20s 内秒杀结束。

则请求 TPS 为：2000000*2/20 = 20 万 TPS

支付：

和下单量数量级类似

计算架构之负载均衡

• 考虑到 QPS 超过 20 万，采用 LVS+nginx 作负载均衡设计

计算架构之缓存架构

• 使用 APP 对商品基础信息进行缓存

计算架构之高可用

• 考虑到下单请求很大，很集中，引入消息队列，进行削峰，具体来说

• 收到下单请求，直接丢入消息队列，并记录超时时间到 redis 集群

• 消息处理端，接收到消息，首先校验是否超时，超时则直接丢弃，未超时，则进行下单处理

• 客户端，轮询查询是否下单成功

7.其他架构设计

可扩展架构设计-微服务拆分

高可用架构设计 - 同城灾备

考虑到目前单机房可以承载，这个作为预案，如果老板了解成本后同意，才做。

大数据架构设计

使用 ClickHouse

1.兼容 SQL，维护使用简单；

2.性能强劲，OLAP 分析平台；