电商秒杀系统

【业务背景】

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

2. 本次6.18秒杀选择了1000个充电宝，10台iPhone12作为秒杀商品;3. 正常的日活大约100万用户;4. 老板要求万无一失。

【技术背景】

1. 技术团队以Java为主，已经落地了微服务架构;2. 主要渠道是自有的App(包括iOS和Android)和微信小程序，为了促进用户转化为App用户，只有下载App才能参加秒杀活动;3. 目前只有单机房。

【毕设要求】

1. 设计完整的架构，例如存储、负载均衡、缓存、高可用、可扩展等;2. 大约10页以内的PPT，每页PPT说明一项设计，包括架构设计和设计理由，无需详细解释备选方案。

【提示】

1. 分析考虑要全面，但并不意味着架构设计要面面俱到，如果分析后认为某些设计点可以不做，就在作业最后统一说明原因即可;2. 如果没有思路，请对照模块9的 IM 案例;3. 如果有的信息觉得不够全或者不够细，可以做出一定的假设，但不能天马行空，需要对照已有的业务背景和技术背景进行合理推断。

业务背景

秒杀商品： 1000个充电宝，10台iPhone12

用户数量：日活100万用户

准时参与秒杀的用户： 100万 * 60% = 60万

业务分析

业务场景

注册：部分新用户为了参加秒杀，下载app进行注册。

登陆：用户会在秒杀活动开始前5分钟集中登陆。

浏览商品：用户会在登陆一直到秒杀活动结束期间不断刷新秒杀商品。

秒杀下单：用户会在秒杀活动开始时集中下单秒杀商品。

支付：只有抢到的用户才需要支付。

性能预估

注册业务在活动之前，量少且分散，暂且忽略。

秒杀场景下，系统所需支持的最大流量即秒杀开启时的峰值。开启后用户会随着时间逐渐减少，即须支撑的QPS：60万。

登陆QPS：60万 / 5 / 60 = 2000 QPS，忽略

支付忽略不计

存储架构设计

数据量并不大，用户数据，数百商品数据，订单数据使用Mysql主备方式可以满足业务需求。针对秒杀商品主要是读场景，使用Redis主从结构提高QPS即可满足。

计算架构设计

高可用设计

分级缓存

分别在APP端，Nginx端进行商品信息缓存以减轻应用服务器和Redis的压力。

多层限流

针对秒杀下单操作，100万用户抢1010件商品，命中率仅为1/1000。因此可以分别在APP端和Nginx端进行90% 和 50% 的限流。

业务需要处理的TPS：60万 * 10% * 50% = 3万

异地备份

异地双活确保活动万无一失

• 计算节点双机房切换

• 单机房做Mysql主备，同时在异地机房进行备份