模块九作业

【业务背景】

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

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

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

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

4. 老板要求万无一失。

【技术背景】

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

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

3. 目前只有单机房。

【毕设要求】

1. 设计完整的架构，例如存储、负载均衡、缓存、高可用、可扩展等；

2. 大约 10 页以内的 PPT，每页 PPT 说明一项设计，包括架构设计和设计理由，无需详细解释备选方案。

【提示】

1. 分析考虑要全面，但并不意味着架构设计要面面俱到，如果分析后认为某些设计点可以不做，就在作业最后统一说明原因即可；

2. 如果没有思路，请对照模块 9 的 IM 案例；

3. 如果有的信息觉得不够全或者不够细，可以做出一定的假设，但不能天马行空，需要对照已有的业务背景和技术背景进行合理推断

业务场景

总体架构

1、日活影响：秒杀一般会进行预热和推广，日活一定会大于平时，预估为平日 5 倍，即 500W；

2、对其他业务影响：本次秒杀的主要目的是为了促进用户转化为 App 用户，所以推广主要是在小程序和 app 内进行，新注册的用户增加不明显，除秒杀外的订单增长也不会特别夸张。

主要影响到的功能：下载 app、登录、浏览商品等；

下载 app 属于一次性活动，登录状态和商品信息可以在 app 缓存数天，可以在秒杀前 3 天不上架和更新商品，现有架构基本可以满足秒杀引起的其他功能；

3、秒杀：秒杀业务是临时性活动，为了避免影响正常业务的功能和复杂度，秒杀环节的功能（主要包括浏览、库存、下单、支付等功能，物流等不属于该环节），需要独立出秒杀微服务。

存储架构设计

存储性能评估

【注册】

日活百万，40%活跃用户，总用户估计在 300 万左右

【登录】

日活百万，登录读取用户信息每天 100 万

【查看商品】

10 个种类，每个种类 20 个商品。商品信息变化概率小，可以作为静态资源存储到 cdn。

【订单信息】

日活百万，每个用户每天 1 个订单，订单信息假如 500K，每天订单量 0.5*100*10000=50000M,约 50G。

【付款信息】

付款信息主要依赖第三方平台，存储账户及支付交易信息信息估计小于订单信息

存储架构设计

存储设计为 mysql 数据库主备设计

计算架构设计

计算性能评估

【注册】

每日新注册用户可以忽略

【登录】

日活百万，由于登录后才能参加描述活动，比如 50%的活跃用户在描述活动前 30 分钟登录，tps

=100w*0.5/(30*60)=278

【订单信息】

由于库存和商品种类限制，1010 商品 1s 内抢完，tps=1010，压测可以准备支持订单 1500tps

【付款信息】

付款信息主要依赖第三方平台，而且成功下单后才会付款，可以不考虑

计算架构之负载均衡

使用 keepalive+nginx，nginx 解决单点故障的问题

计算架构之缓存设计

秒杀商品的文本和图片信息可以在活动前下发到 app 缓存。web 容器主要缓存静态资源。秒杀商品可以根据库存数量提前在 redis 队列里面生成一个个元素。页面的商品库存数量，用户余额等也可以放到 redis 里面。

可扩展设计

高可用设计

由于先期访问量不大，运行效果未知，可提供单机房，可用性取决该机房的稳定性，只能做到同城单中心，后期如果有时间和成本，百万日活架构最做成同城双机房双活