架构实战营 - 毕业设计

性能需求分析

假设所有用户都参与秒杀活动

app 下载

假设公司提前 15 天开始宣传，此前已有 30%的用户下载过 app 了，70%的用户在 15 天内下载 app，假设下载时间集中在每天 12-14 点和 20-23 点，

QPS 为：（100 万*0.7）/（15*3600*5）≈ 2 QPS，可以忽略不计

看商品

假设用户在促销开始前 10 分钟打开 app 等待，看商品的 QPS 为：100 万/（60*10）≈ 1700 QPS

抢购

假设用户全部在 10 秒内点击抢购，则 TPS 为：100 万/10 = 10 万 TPS

用户可能在抢购时多次点击抢购按钮，对于秒杀场景，如果第一次没有抢购到，后续也不可能抢到了。客户端需要限制，如果用户第一条抢购信息发送成功，继续点击不发送消息。

存储架构设计

1. 促销不会引入大量新商品、新商家，商品和商家数据几乎不变

2. 不会导致用户数量大量增长

3. 1000 个充电宝，10 台 iPhone，订单数据量不大

综上，存储系统任用原来的，不做设计

缓存架构设计

商品信息缓存在 Redis，看商品的 QPS 只有 1700，单台 Redis 性能完全足够，使用主备架构即可

使用 Redis 缓存商品数量，便于订单生成时快速扣减库存，提高系统处理效率。商品数量少，没分片必要，使用主备架构即可

计算架构设计

已经落地了微服务，适当扩展节点数量即可，不用修改

使用 Nginx 集群做负载均衡

服务集群使用漏桶做过载保护，不管是未抢到商品，还是被拒绝的请求，前端直接提示抢购失败即可

架构图

灾备方案

1. 存储系统崩溃：安排人员值班，及时发现并重启，订单信息已经存储在 Redis 了，不会丢失

2. Redis 崩溃：备库升级为主库。备库信息不是最新的咋办？允许少量超卖。看不见商品？客户端缓存

3. 机房断电：同城双中心，由于现阶段商品数量少，双活架构意义不大，先使用灾备架构