电商秒杀系统设计

业务背景

日活百万

10 品类 20 个商品

正常日活百万

秒杀 1000 台充电宝 10 台 iphone12

存储架构

系统的主要应用场景为用户注册、用户交易、平台管理品类及库存、用户检索浏览商品、系统记录访问日志

数据规模

系统主要的数据存储为：用户数据、商品数据、交易数据、系统访问应用日志

商品数据量：10 品类、20 个商品数据，商品描述信息包含数据、图片等信息，数据的库存信息等内容，假设每类库存单条数据 1K，库存量为每类 100 万条，则库存商品数据 1K*200*1000000/1024/1024= 200G。品类信息只有 200 可以忽略。

用户数据量: 单用户信息 10K，按可扩展考虑，用户量按 2000000 用户估计，则用户数据量 10K *2000000/1024/1024=20G

交易数据量：每日交易量转换率为 10%，及每日成交量为 10 万次，每次交易信息 10K，数据存储要求为 3 年，10K *1000000 *10%*365*3/1024/1024=1095G，交易数据考虑数据安全性。

访问数据量：日活百万，用户操作需记录条数 20 次，则每日操作记录 2 千万，每次操作日志 1K，数据存储要求为 3 年，60000000*1K*365*3/1024/1024=21900G

则所需的存储量，实际存储需求为 3.3T，交易数据、用户数据、商品数据采用 3 副本方式，访问数据采用 1 副本，则需要存储约为 8T。

存储架构：mysql 主从模式（一主两从），系统访问日志使用 ES 进行存储。交易数据增量同步到 ES 集群中。

计算架构

系统的主要应用场景为用户注册、用户交易、平台管理品类及库存、用户检索浏览商品、系统记录访问日志

新用户注册用户每天不会超过 1 万，可以忽略

系统访问量：日活百万，并假设每日登录次数为 3 次，每天登录时间集中在 8 点到晚上 11 点共 15 小时，则登录 TPS 为 1000000*3/15/3600=50

用户交易：每日交易量转换率为 10%，及每日成交量为 10 万次，每笔交易涉及交易信息写入、库存信息扣除操作为 3 次，每天操作时间集中在 8 点到晚上 11 点共 15 小时，则登录 TPS 为 1000000*10%*3/15/3600=5

平台日志记录：日活百万，用户操作需记录条数 50 次，则每日操作记录 50*10000000，每天操作时间集中在 8 点到晚上 11 点共 15 小时，则日志记录 TPS 为：100000000/15/3600=7000

用户检索浏览商品：日活百万，并假设每用户每日检索及查看商品 30 次，每天操作时间集中在 8 点到晚上 11 点共 15 小时，则检索的 QPS 为 30*1000000/15/3600=500

1、日志记录写入到 ES 中，同时应对用户检索采用 redis 主从模式缓存商品信息，交易数据 TPS 大约为 5，可以忽略。

2、TPS+QPS=8000 使用 nginx 集群即可。直接使用 nginx+vip

缓存

APP 缓存+应用缓存+分布式缓存即可。商品数据种类信息直接放入缓存，图片使用 CDN 方式

秒杀功能支撑

秒杀 1000 台充电宝 10 台 iphone12

请求拦截：

秒杀的瞬时并发，通过多层拦截方式。

1、nginx 的时间验证处理，秒杀会在 5 秒内结束，用户访问在秒杀开始 5 秒后请求自动返回活动结束。

2、redis 缓存实现活动令牌，令牌数量设置为秒杀数量，同时对同一用户的多次重复请求进行验证

3、通过后通过消息队列核减库存后，同步 db，并回复界面。

可扩展

采用微服务架构模式

用户服务 库存服务 交易服务（支付） 检索服务 秒杀服务 认证服务 日志服务

高可用

同城双中心（灾备）

跨机房业务保障