架构实战营毕业设计

业务背景

你作为一个电商创业公司的架构师，负责设计 6.18 大促秒杀系统的设计，你们的业务模式如下：你们挑选选品各大电商平台上畅销和好评的商品进行销售，每个品类不超过 20 个商品，目前做了 10 个品类；

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

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

• 老板要求万无一失。

技术背景

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

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

• 目前只有单机房。

业务分析

1. 微信小程序用户参与时需要下载 APP,并从 APP 登录

2. 通过 APP 注册/登录

3. 秒杀商品为 1000 个充电宝，10 台 iphone12

核心业务场景

• 下载 APP

• 注册/登录

• 秒杀

总体架构思路

当前需要解决的核心场景有 3 种，需要考虑

1. 下载 APP ： 需要高速的下载分流

2. 注册/登录 ： 由于日活用户规模百万以上，那么总用户规模达到千万以上，需要考虑存储高性能与计算高性能

3. 秒杀 ： 秒杀商品不多，总量只有 1010 个，需要考虑计算高性能

存储架构设计

性能估算

下载 APP

由于下载用户分散在全国各地，为保证用户下载都能正常，首先是考虑：

1. 在各大应用市场上架

2. 通过自有渠道平台下载（如官网、H5 等），此部分可以通过CDN分流实现。

注册

千万用户注册信息

登录

百万日活用户，每天登录数据是每天 100 万

秒杀

秒杀商品只有 1010 个，数量很少。但由于秒杀库存读取量较大，考虑分布式缓存

存储架构设计

1. MySQL 主备，同步用户数据+秒杀结果（1000 万注册信息，100 万登录信息，1010 个秒杀订单）

2. Redis Cluster，存储秒杀商品的库存

计算架构设计

性能估算

下载 APP

不涉及

注册

每日新增用户不足一万，可忽略

登录

在秒杀开始前 1 个小时内，用户可能会大量登录，按日活用户 5 倍估算，登录的 TPS 均值为：500 万/3600=1400

秒杀

秒杀时，在开始的 10 秒内，会有大量用户请求，秒杀的 TPS 均值为 500 万/10=50 万

计算架构设计

由于注册、登录、下载的 TPS 比较低，暂不考虑

由于秒杀的 TPS 已达到 6 万，设计如下方案

1. 客户端削峰 - 请求秒杀时，本地计算是否失败，如计算失败，则后续请求都不发送到服务端，预计削减 90%，剩余 TPS : 500000*10%=50000

2. WEB 缓存削峰 - 应用内使用限流算法，再次削减请求 90%，剩余 50000*10%=5000

3. 削减后的 TPS 已在可承受范围内

计算架构之负载均衡

1. 前端使用 F5 负载均衡，业务集群内使用 Nginx+keepalived 代理

2. 业务服务器集群接收请求

计算架构之缓存架构

1. APP 缓存削峰

2. web 容器削峰

3. 使用分布式缓存秒杀商品库存

其他架构设计

高可用架构设计

因为老板需要保证万无一失，因此考虑系统高可用，但是因为目前用户规模只有百万级别，不需要考虑异地多活。

所以选择同城双中心，不选择同城灾备是因为手动切换需要时间，不符合老板万无一失的要求