要求

业务性能分析

业务场景

• 待秒杀商品提前加载入 Redis 缓存

• 秒杀前 10 分钟用户集中登录 App

• 秒杀前用户频繁刷新对应商品页

• 秒杀请求通常集中在活动开始后 10 秒内

• 秒杀成功的订单在 5 分钟内完成支付

性能分析

• 正常日活 100 万，假设由于 618 活动预热，当天日活数翻翻达到 200 万，其中 30% （60 万）会参与秒杀活动。

• 秒杀前 10 分钟登录请求 60 万，QPS = 600,000 / 10 / 60 = 1000

• 秒杀请求有 3 种返回结果：成功，售罄，失败。

• 成功和售罄的情况下用户均无法再次参与秒杀。

• 失败是由于高并发情况下系统未成功处理请求，用户可能会重新点击秒杀重试。假设平均每个用户重试两次。

• 由此估算秒杀 TPS = 600,000 * 2 / 10 = 120,000

存储架构

• 秒杀活动主要由 Redis 集群来处理，包括商品预览，库存实时刷新等；

• MySQL 用于数据持久化。

负载均衡

• 由于公司目前还在创业阶段，故不考虑 F5。采用三级负载均衡架构

缓存设计

高可用架构

• 系统正常日活在百万级别，暂不考虑异地多活

• 老板要求万无一失，采用同城双中心