【业务背景】

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

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

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

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

4. 老板要求万无一失。

【技术背景】

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

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

3. 目前只有单机房。

总体架构设计思路

假设每天活跃用户占全部用户的 40%，则平台用户数量为 250 万。

假设 6.18 大促当天，新注册用户 10 万，并且该 10 万用户均为当天活跃用户。

假设目前的 Java 微服务有，用户服务，商品服务，订单服务。

这边先按照百万级的秒杀系统来设计架构，因为老板需要万无一失，则部分架构设计可能需要按照千万级秒杀系统来做架构设计。

存储性能估算

注册

百万用户注册信息。

登录

平台用户 250 万，6.18 当天活跃用户 60%，加上新注册用户 10 万，累积 6.18 当天登录用户 160 万用户，登录是读取用户信息当天为 160 万 QPS，假设用户都是通过小程序后打开 app 应用，有 90%的活跃用户都下载了 APP，且当天需要登录 APP，则读取用户信息当天约等于 300 万 QPS。

下载 APP

假设 6.18 新增注册用户 10 万，其中 90%用户下载了 APP，则下载为 9 万 QPS。

商品

每个品类不超过 20 个商品，目前做了 10 个品类，一共大约 200 个商品。假设用户都是从商品列表页进入商品详情页，则 160 万活跃用户都会进入商品列表页，假设当天活跃用户每人访问商品列表页为 50 次，普通商品访问评率为 10 次，秒杀商品访问频率为 30 次：

1. 商品列表页读取量：160 万 * 50 = 9000 万/天。

2. 普通商品详情读取量：160 万 * 10 = 1600 万/天。

3. 秒杀商品详情读取量：160 万 * 30 = 4800 万/天。

订单

按照下单转化为 20%，假设每一笔订单仅需要支付一次就成功，且会存储支付记录，且支付成功后跳转到订单详情页面，则：

1. 普通商品订单写入：1600 万 * 20% = 320 万数据。

2. 秒杀商品订单写入：1000 + 10 = 1010 条数据。

3. 订单记录写入：320 万 * 1 = 320 万条数据。

4. 订单信息读取：320 万 * 1 = 320 万/天。

所以我们按照 320 万数据进行存储架构设计。

存储架构设计

订单服务，用户服务，商品服务MySQL主备，商品服务Redis Cluster

1. 260 万注册用户信息，300 万登录请求，320 万订单数据，320 万支付数据，1010 条商品数据

2. 商品列表页 9000 万读请求/天，商品详情页 6400 万/天。

计算性能估算

注册

假设 6.18 新注册用户 10 万。

登录

平台用户 250 万，6.18 当天活跃用户 60%，加上新注册用户 10 万，累积 6.18 当天登录用户 160 万用户，登录是读取用户信息当天为 160 万 QPS，假设用户都是通过小程序后打开 app 应用，有 90%的活跃用户都下载了 APP，且当天需要登录 APP，则读取用户信息当天约等于 300 万 QPS，假设登录时间几种在早晚 4 小时，登录的 TPS 均值：300 万 / 14400 = 200。

下载 APP

假设 6.18 新增注册用户 10 万，其中 90%用户下载了 APP，则下载为 9 万 QPS，该压力基本是在 app 下载应用。这边可以忽略。

商品

每个品类不超过 20 个商品，目前做了 10 个品类，一共大约 200 个商品。商品为平台手动录入，TPS 可以忽略不计。

订单

按照下单转化为 20%，假设每一笔订单仅需要支付一次就成功，且会存储支付记录，且支付成功后跳转到订单详情页面，为了减少压力，当天的秒杀分布在上午 10 点，到晚上 8 点，每隔一个小时一次秒杀，一共 10 场秒杀，假设秒杀开始后 1 分钟抢完所有的秒杀商品，假设前端随机丢弃请求 50%则：

• 下单的 TPS 为：320 万 / 10 / 60 * 50%≈ 2600TPS

计算架构设计

负载均衡

缓存架构