架构训练营 毕业设计

电商秒杀系统

【业务背景】

你作为一个电商创业公司的架构师，负责设计 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. 如果有的信息觉得不够全或者不够细，可以做出一定的假设，但不能天马行空，需要对照已有的业务背景和技术背景进行合理推断。

业务分析：

6.18 秒杀商品为 1000 个充电宝、10 个 iphone 12 手机，这个商品必须保证强一致性

10 个品类 20 个商品作为销售热点商品，要保证缓存必然不失效，保证最终一致性

而且最好是多级缓存

正常日活为 100 万，预计秒杀活动会有所增加，不过又必须下载 APP，所以可以按 120 或者 150 万的日活考虑，更重要的是秒杀时间的瞬时高并发。

目前是单机房，要秒杀活动保证万无一失的话，可以同城双机房，其中另一个机房专门做秒杀活动，如果出故障可以由主机房接管

复杂度分析：

高性能：秒杀活动要应对瞬时高并发，比如秒杀时间刚到

高可用：老板要求万无一失

高扩展：已经是微服务架构，可以通过增加机器来应对大部分，方便做双机房

业务基本场景：

注册登录：因为有 APP 限制，正常日活 100 万，整体用户加上增加应该也就 4、500 万

查询商品：10*20 = 200 个商品促销（热点商品）

创建订单：要有剩余商品才能创建，之后订单扣减的商品生命期跟随订单，订单 15 分钟

付款：订单有效期内付款有效

存储性能估算：

热点商品有 200 个

秒杀商品 1010 个

总用户大概 4、5 百万人

剩下的就是订单量

用 mysql 主备架构可以满足要求

存储架构设计

计算架构性能估算

假设秒杀时间一到，会有大概 150 万用户参与

假设每秒全都发一条创建订单，会有 150 万

查询，每个品类一个业面来分流，则会有 150/10 * 200 = 3000 万

计算架构负载均衡

计算架构之缓存架构

因为热点数据没有太多，感觉用容器缓存就够了

高可用

我们有 APP 和微信小程序，应该是共用账号的机制，也就是说 APP 也应该支持微信登录，那么核心的登录业务就天然支持高可用

我们已经建立了完善的微服务架构，所以只对秒杀活动做双机房并没有太大难度

所以可以将这次的秒杀活动放到另一个机房，来保证秒杀活动的万无一失

而且以后秒杀活动下去后，还能取消掉这个机房，也不算浪费

限量秒杀的 1010 个商品，需要强一致性，所以要全放主机房

其他的都可以通过消息队列，根据参与时间来搞

限流以及脚本检测：因为秒杀活动可能有些人会写脚本疯狂刷抢，为了保证所有良好市民的权益，要做一些检测和防护，刷掉一些脚本发来的命令，并且每个人每个订单最多十件，秒杀商品最多一件

高扩展

本身已经是微服务架构，感觉已经有高扩展性了