业务分析

• 商品种类仅两种，活动页面、商品详情可通过缓存预热方式直接将流量在 CDN 处处理

• 秒杀活动仅在 App 端开展，可在 App 端通过随机丢弃请求等方式前置限流

• 库存应单独处理，且秒杀活动中成功秒杀的用户支付意愿很高，即便抢到的用户最后未支付，也不必考虑重新释放库存，因此在 Redis 处 INCR 即可，其结果大于库存数的即是未秒杀成功的

存储架构设计

存储性能估算

• 总计只有两种商品，缓存命中率可达近 100%，商品详情的 QPS 对存储性能影响可忽略

• 假设 1010 件商品在 10 秒内被抢完，订单 TPS 为 1010/10=101

• 总计 1010 件商品，可放进 10000 流量至 Redis 查询库存，库存 QPS 为 10000/10=1000

存储架构设计

• 由 MySQL 负责订单数据，Redis 负责库存数据。这两者的 QPS、TPS 均不高，主备架构足以应对

计算架构设计

计算性能估算

• 假设依靠活动营销吸引了一部分用户，活跃用户达到平日的两倍，最终有 50%的用户参与了秒杀，最终参与的用户仍为 100 万，前置限流削去 50%的流量，已经秒杀失败的用户直接在 App 端限制其不能继续尝试，则 QPS 为 50 万/10 秒=5 万

负载均衡

• 由 nginx 负责负载均衡即可

缓存架构

• 缓存主要由 CDN 应对活动页面和商品详情，节约服务器资源用以应对库存和订单