毕业设计项目

设计电商秒杀系统

【业务背景】

你作为一个电商创业公司的架构师，负责设计 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）瞬间并发请求很高

-要避免瞬间涌进的请求不会导致系统瘫痪

2）供不应求

-要购买的人远远超出库存，要防止超卖

业务基本场景

1）刷秒杀详情页

静态、动态数据分离

静态数据如：商品详情，价格，缓存在 app 端

动态数据如: 库存存在数据库，用 redis 做缓存

2）下订单

秒杀按钮，在秒杀时间开始前，库存为零，秒杀失败都不能点击

如果按钮成功，则进入排队下订单。

先从 redis 查询库存，如果库存为零了，就不能创建订单，

如果库存不为零，则在数据库扣除一个库存，并更新 redis 缓存，接着使用消息队列创建订单（异步请求），然后让用户支付。

3）支付

支付成功，就完成订单，

如果超时，就当作支付失败，自动归还库存

假设

1）当天有 50 万用户同时进来秒杀

2）秒杀详情页 5 分钟前开放

3）每一个用户都必须登入

5)秒杀一开始，大家同时点击秒杀按钮

存储性能估算

1）秒杀页面详情

使用静态页面缓存

2）秒杀活动资料

库存和秒杀时间 ，数据不多可以略过

3）下订单

1000+10=1010

4）支付

1000+10=1010

存储架构设计

储存秒杀活动资料，如订单，库存等等。其他的资料如商品详情，用户资料通过其他服务接口。

使用 redis sentinel 来达到高可用的缓存(缓存库存等资料）

计算性能估算

1）刷秒杀详情页 （库存的刷新）

50 万/10 = QPS5w (在 app 限制每 10 秒只允许刷一次）

由于商品详情已经缓存在 app, 这里主要是库存的刷新

2）下订单

QPS 50w

3）支付

TPS1000

计算架构设计

负载均衡设计

缓存设计

App 缓存: 静态商品数据，秒杀结果，库存

web 缓存 : 静态商品数据，库存

分布式缓存：详情页（静态数据、动态数据）、剩余库存、订单信息

可扩展架构设计

秒杀服务独立部署即可

微服务拆分：

拆分成四个部分：

-库存：

-订单

-支付

-排队

高可用架构设计

就一个机房，暂时先不做灾备处理

削流设计：

1）在 app 前端页面，相关按钮点击后置灰，防止重复提交。

2）在 nginx 的部分，限制同一个 userid 在每 10 秒只能发送一个 request,多过这个数目就按秒杀失败处理。如果是库存刷新，被拒的 request，直接返回本地的库存缓存。

这里我们只放行秒杀库存的数量（1000 个）请求到后端服务，并采取分段放行（避免库存被机器人和自动脚本抢走），分段放行，除了限制了机器人和自动脚本，把请求分散在各个时间段，还进一步缓解了后端服务的压力。

创建订单可以走异步消息队列。排队服务接到下单请求，直接放进消息队列，订单服务取出消息后，先将订单信息写入 Redis，每隔 100ms 或者积攒批量订单，批量写入数据库一次。前端页面下单后定时向后端拉取订单信息，获取到订单信息后跳转到支付页面。用这种批量异步写入数据库的方式大幅减少了数据库写入频次，从而明显降低了订单数据库写入压力。