0.作业要求

设计电商秒杀系统

业务背景

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

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

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

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

• 老板要求万无一失。

技术背景

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

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

• 目前只有单机房

1.业务分析

• 日活用户大约 100 万，按照 30%~40%活跃用户比例估算，总用户大约 300 万

• 本次设计只包含秒杀功能，其他基本功能如注册、登录、普通商品浏览、购买都已实现

• 秒杀系统包含以下 2 个功能

• 浏览秒杀商品

• 抢购秒杀商品

• 假设有 50%的活跃用户以及 10%的非活跃用户会参加秒杀。秒杀参与人数为：100 万*0.5+(300 万-100 万)*0.1=70 万

• 浏览秒杀商品的估算如下

• 浏览商品的请求峰值发生在秒杀开始前 5 分钟和开始后 10 分钟，所有参与者平均刷新每件商品各 5 次

• 峰值 QPS: 70 万*2*5/(60*15)=8000/秒

• 抢购秒杀商品的估算如下

• 抢购的峰值请求发生在活动开始后的 2 分钟内，假设每人在峰值的 2 分钟内向两种商品各发起 3 次抢购请求

• 抢购请求的峰值 QPS：70 万*2*3/60/2 = 3.5 万/秒

• 假设所有商品在活动开始后 1 分钟内全部被秒杀

• 抢购请求的峰值 TPS：(1000+10) / 60 = 17/秒

2.存储架构设计

• 只有两种商品参与秒杀，即使未来秒杀商品增加也最多 200 种商品

• 订单数量只有 1010 条，存储空间需求很小

• 为了保证可用性，采用 Redis 主备方案

3.计算架构设计

• 整个秒杀系统的 QPS+TPS 峰值请求量约为 5 万/秒

• 以一台服务器处理量为 2000/秒，需要 25 台服务器

负载均衡

缓存架构

• App 端会对请求频率过快的设备暂停 5 秒向服务器发送新请求

• Web 容器端缓存静态文件

• Redis 本身就可以用于缓存数据库

服务限流

• App 端：对请求频率过快的设备暂停 5 秒向服务器发送新请求

• 后端：采用漏桶算法，减少丢弃请求

4.高可用架构设计

秒杀系统对公司的声誉、新用户的获取至关重要，可以考虑建立同城双中心做灾备