618 大促 100 用户级秒杀系统架构设计

【业务背景】

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

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

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

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

4. 老板要求万无一失。

【技术背景】

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

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

3. 目前只有单机房。

【业务分析】

【架构设计】

存储架构

存储性能分析

注册：假设小程序有 30%用户，即：30 万用户下载后注册

登录：百万注册用户，每天活跃用户有 40%，登录时读取用户信息是每天 40 万。

商品查看：每个活跃用户查看 Iphone 20 次和充电宝 5 次，40 万*20+40 万*5 次共 1000 万次查看。

秒杀下单：每个活跃用户参与秒杀次数为，40 万用户*1012 个商品=4 亿

订单查看：活跃用户中只有秒杀成功的用户会查看订单，实际 1000+12=1012

存储架构设计

计算架构

计算性能分析

注册：假设小程序有 30%用户，即：30 万用户下载后注册

登录：百万注册用户，每天活跃用户有 40%，登录时读取用户信息是每天 40 万。

商品查看：每个活跃用户查看 Iphone 20 次和充电宝 5 次，40 万*20+40 万*5 次共 1000 万次查看，QPS=1000 万/3600s = 3000。

秒杀下单：每个活跃用户参与秒杀次数为，40 万用户*1012 个商品=4 亿/3600s = 11 万 TPS

订单查看：活跃用户中只有秒杀成功的用户会查看订单，实际 1000+12=1012

负载均衡架构

缓存架构

同城多活【备用】

【总结】

1. 考虑安全性设计，防止爬虫、黑客攻击；

2. 可扩展性设计，后续进行服务重构、服务拆分。如果有其他类似平台或服务则可以考虑中台设计

3. 考虑可用性则可以采用异地多活架构设计等。

4. 当业务量继续扩大，可以考虑采用大数据对数据进行存储与分析

5. 当商品数量增多，可以采用 es 实现数据搜索与分析