架构 1 期模块九作业

业务背景

1）挑选了 10 个品类，每个品类下 20 个商品，总共 200 个商品参与活动;

2）准备了 10 台 iPhone12，1000 个充电宝参与秒杀活动。

约束与限制

1）用户下载 APP，注册登陆才能参加秒杀活动；

2）技术团队以 JAVA 为主，已落地微服务架构；

3）目前只有单机房；

总体架构思路

原来电商系统分为 3 个子系统，商品系统、订单系统、会员系统。

因为已落地微服务架构，现需要增加一个秒杀系统并将其分离出来，故现在有四个系统。根据三个火枪手原则，后台需要至少 12 位技术人员维护系统。正常日活为 100 万，总用户不超过千万。假设大促的日活增长为原来日活的 300%，即 300 万日活。因此综上考虑，需要做一个百万用户规模架构设计。

存储架构设计

注册

大促日活 300 万，假设用户转化为 APP 用户的概率为 20%，新注册用户为(300 万-100 万）*20%=40 万

登录

正常日活百万，考虑到预留量，登录读取用户信息每天 300 万 QPS。

目前做了 10 个品类，每个品类 20 个商品，考虑预留量为 2 倍，未来总共的商品个数可扩展到 10*20*2=400 个。

假设每个商品所有文本信息约为 200 字节，则商品的数据存储量=10*20*2*0.2M=40M，一个商品图片信息约为 30M，则 图片数据存储量=10*20*2*30M=12G。

计算架构设计

数据量

注册

新用户数量可忽略不计

登录

大促日活 300 万，假设有 40%的活跃用户在前 10 分钟涌入，则 300 万*40%/600s=2000QPS/s。

秒杀

假设 10 台 iphone12 在 1s 内秒完，QPS 为 40 万/1s=40 万 QPS；

1000 个充电宝在 1 小时内秒完，QPS 为 40 万/3600s=100QPS/s。

订单

假设大促当天的订单转化率为 10%，则订单数为 300 万*10%=30 万,订单主要集中在前 2 小时，则 QPS 为 30 万/7200s=400QPS/s

缓存

购物是一个典型的读场景，非常适合用缓存架构，由于请求量大，负载均衡也需要。

秒杀商品十分重要，为了减少受损情况应缓存请求，避免出现雪崩效应，尽量减少丢弃，可以使用漏桶算法的写缓冲。

微服务架构

在原有微服务系统的基础上再增加一个秒杀系统；为保证万无一失，可以做同城双中心。

12 个程序员统一语言为 JAVA，无需多语言开发 SDK，因此微服务框架模式选择嵌入 SDK 模式，如有 RTC 要求，选择 Dubbo,否则选择 Spring  Cloud。