架构实战营模块九作业

1 业务分析

1）正常日活约 100 万用户，按每天活跃用户占 40%，推算出总用户量为 250 万；

2）主要渠道为自有 App 和微信小程序，假设比例为 6:4，在秒杀活动诱惑下，用户比例转为 7:3，即 App 用户为 250*0.7=175 万，小程序用户为 75 万；

3）假设 App 用户中有 30%参加秒杀活动，即秒杀参与用户为 175*0.3=52.5 万；

4）假设下单超 15min 未支付，则系统自动取消订单；

5）商品共 10 个品类，每类不超过 20 种商品，总量不超过 200 种商品；假设每个商品的信息（文字+图片）不超过 3M，则所有产品信息最大为 200*3M=600M。

2  存储架构设计

2.1  存储性能估算

【注册】

250 万用户注册信息。

【登录】

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

【商品】

总商品不超过 200 种，产品信息不超过 600M，可忽略不计。

【日常交易信息】

用户日活 100 万，假设每个用户每天下单一次，则每天新增 100 万笔交易记录。

【秒杀商品及交易信息】

由于秒杀商品仅 1010 个，产生的交易记录几乎可忽略不计。

2.2  存储架构设计

3 计算架构设计

3.1 计算性能估算

【注册】

每日新注册用户可忽略。

【日常登录】

每日 100 万用户登录，假设登录时间集中在 4 小时，则登录 TPS 为 100 万/14400≈70。

【秒杀登录】

假设秒杀用户在活动开始前 30min 内登录，则秒杀登录 TPS 为 52.5 万/1800≈292。

【秒杀信息查看】

假设秒杀用户在活动前 1min 内平均刷新 3 次活动商品秒杀信息，则秒杀信息查看的 QPS 为 52.5 万*3/60s≈26250。

【秒杀商品下单】

假设秒杀用户秒杀请求有 1%传递给服务端，且秒杀商品在 1s 内完成抢购，则秒杀商品下单 TPS 为 52.5 万*1%/1s=5250。后续未支付订单重新被抢购的 TPS 可忽略不计。

【秒杀订单支付】

假设约 2000 笔订单（按商品总数做一定余量，超过 1010 的商品后，后续订单支付不成功），在 15min 内支付完毕，则订单支付 TPS 为 2000/900≈3。

3.2 计算架构设计

【计算架构之负载均衡】

【计算架构之缓存架构】

4 可扩展架构设计

按当前业务量来说，需要拆分成微服务架构，其中微服务个数按三个火枪手原则进行规划。

5 高可用架构设计

由于目前是单机房部署，可用性取决于该机房的稳定性，若要达到老板要求的万无一失，需考虑做成同城双中心架构。

6 大数据架构设计

故事即将结束，旅途并未停止，让我们大步往前走，共同期待美好的未来吧！