✅压测600没问题，上线后300就扛不住了，可能是什么原因？

典型回答

✅什么是压测，怎么做压测？

大多数时候，压测能压倒600，实际上也是可以扛得住600的，但是也有些特殊情况，我们其实就是发生过，比如下面我要介绍的数据倾斜问题、外部系统影响等问题，都是比较常见的。

以下就是一些可能的情况。

冷启动问题（不常见）

所谓冷启动，就是机器可能刚刚启动，里面的东西都是冷的，比如缓存、热点代码等等。问题中没说什么时候扛不住的，那么有可能在应用刚启动的时候扛不住了。这时候有这么几种常见的情况了。

• 缓存未预热
  生产环境启动时缓存为空，那么就会有大量请求穿透到数据库，导致DB负载激增，而且DB的RT也要比缓存长。而压测环境可能已预加载数据，并没有暴露这个问题。

✅如何在Spring启动过程中做缓存预热

• JIT编译延迟
  Java应用冷启动时，JIT编译器尚未优化热点代码，初始阶段吞吐量低。压测持续运行后JIT优化生效，但生产环境刚上线时性能未达峰值。

✅Load飙高问题排查过程

• MQ消费延迟
  生产环境可能存在历史消息堆积（如Kafka未消费消息），消费者启动后需处理积压消息，占用大量资源，导致业务接口资源不足。

这种情况并不太常见，或者说不是本身不常见，是和压测有关的不常见，一般如果做好优雅上下线了，都会可以很好地解决这个问题，还有就是如果在刚启动的时候，RT比较高、Load或者CPU比较高，可以考虑这个问题。

定时任务干扰（常见）

• 资源抢占
  生产环境定时任务（如报表生成、数据归档）可能在高峰期运行，消耗大量CPU、IO或数据库连接，导致业务接口响应延迟。

• 锁竞争
  定时任务涉及批量数据操作（如全表更新），可能引发数据库锁竞争，阻塞业务SQL执行。

未进行全链路压测（很常见）

压测的时候可能只覆盖了单个服务，未模拟依赖链路的真实负载（如支付、风控服务）。生产环境中，下游服务性能瓶颈（如第三方API限速）拖累整体性能。

✅什么是全链路压测？

外部系统影响（常见）

• 第三方服务降级
  生产环境依赖的外部服务（如短信网关、支付接口）存在限流、高延迟或故障，触发熔断机制，导致业务线程阻塞。

慢SQL与数据问题（很常见）

为啥压测的时候没有慢SQL呢。没有数据问题呢？因为压测可能是之前进行的，而线上的数据是不断地变化的。随着时间的迁移，就可能出现问题了。

• 数据倾斜
  生产环境存在热点数据（如某大V用户被频繁访问），导致数据库单分片负载过高，或缓存频繁失效。

• 索引失效
  生产数据量增长或查询条件分布变化，导致原本有效的索引失效，引发全表扫描。

✅为什么MySQL会选错索引，如何解决？

• 数据隔离差异
  压测环境使用隔离的测试数据，有的时候数据都是我们自己造的，一般造出来的数据都比较工整，而而生产环境的数据不仅规模更大、而且也要更加复杂的得多。所以有些问题并不一定能暴露的出来。

压测环境偏差（常见）

• 硬件/配置差异
  压测环境使用更高配服务器（如CPU核数、内存）、独立数据库实例，而生产环境为共享集群或容器化部署（资源受K8s限制）。

• 网络拓扑差异
  生产环境存在跨机房调用、公网传输（如OSS存储），而压测环境为内网低延迟链路。

其他接口QPS干扰（常见）

这个和前面那个定时任务干扰差不多的情况。压测的时候一般选择业务低峰期，只针对受压接口进行压测，而其他接口可能QPS并不高。但实际生产环境中，可能并不一定，题目说300QPS，没说是单接口还是整体。有可能虽然单接口可能才300，但是多接口加一起可能就高的多大了。

基础设施问题（常见）

压测的时候和真实的生产环境中，基础设置可能有一定的差异。比如MQ、数据库、Redis等等，都有可能，他们的线程池大小、CPU情况，内存情况，都是有影响的。

而且有些时候，这些中间件是共用的，可能你的QPS并不高，但是其他系统可能很高，占用了更多的中间件资源，那么其他系统就可能被拖垮了。

还有就是线上系统，可能有很多其他的开销，比如ELK日志采集，SkyWalking的监控，都会占用一定的资源的。