压测 QPS 到 5 万，实际峰值才 3 万，服务却挂了。压测不等同于真实流量——复盘 5 个经典的压测盲区。

一、问题背景

  • 1.1 压测结果——全链路压测 5 万 QPS，99 分位 RT 正常
  • 1.2 实际情况——峰值 3 万 QPS，多个服务超时
  • 1.3 现象——数据库 CPU 100%，连接池耗尽

二、盲区 1：压测数据分布不均

  • 2.1 压测数据——均匀分布，每个用户访问量差不多
  • 2.2 真实数据——20% 的热点用户产生 80% 的请求
  • 2.3 热点用户导致热点 Key（Redis）/ 热点行（DB）
  • 2.4 改进——压测数据模拟真实分布（长尾分布）

三、盲区 2：未压测写链路

  • 3.1 压测重点在读——浏览商品、搜索
  • 3.2 真实流量——下单、支付等写操作占比不低
  • 3.3 写操作的锁竞争——行锁、Redis 分布式锁
  • 3.4 改进——写链路按真实比例压测

四、盲区 3：依赖服务的容量

  • 4.1 压测 Mock 了下游服务
  • 4.2 真实场景——下游服务慢、超时、限流
  • 4.3 级联超时——上游等下游，下游等数据库
  • 4.4 改进——全链路压测不通 Mock

五、盲区 4：冷数据 vs 热数据

  • 5.1 压测时缓存已预热——命中率 95%
  • 5.2 大促当天——新商品、新用户缓存未命中
  • 5.3 缓存穿透到数据库——瞬间打爆
  • 5.4 改进——大促提前预热缓存

六、盲区 5：长尾延迟

  • 5.1 压测关注平均 RT 和 P99
  • 5.2 真实场景——P999 远大于 P99
  • 5.3 长尾导致线程池积压
  • 5.4 改进——关注 P999 和最大 RT

七、总结

  • 压测不通过的肯定不行，压测通过的也不一定行
  • 关键——压测数据分布、写链路、全链路