如何将Spring Boot在1000QPS下的P99延迟降至500毫秒以内

针对你遇到的问题——单请求实际执行耗时<20ms，但1000VUs压测下P99延迟超3s，结合当前仅5个可运行线程的状态，以下是具体优化措施：

一、核心问题定位 #

当前仅5个runnable线程，远低于Tomcat配置的最大400线程，说明大量线程卡在Redis IO等待状态，必须先打通线程阻塞点，才能让线程资源被充分利用。

二、针对性优化措施 #

1. 优化Redis操作与客户端配置 #

• 合并Redis请求：把6次串行Redis读取改为批量操作（比如用MGET/HMGET命令），将6次网络往返压缩为1次，直接降低IO耗时。
• 调整Redis连接池参数：
  若使用Jedis：确保spring.redis.jedis.pool.max-active与Tomcat最大线程数匹配（比如设为400），同时设置合理的max-wait（如100ms），避免线程长时间等待Redis连接。
  若使用Lettuce：确认是否启用异步API或正确配置连接池，Lettuce默认异步非阻塞，误用同步API会导致线程等待。
• 排查Redis实例性能：压测期间监控Redis的CPU使用率、QPS、单命令延迟，若Redis本身存在慢查询或资源瓶颈，需扩容Redis实例。

2. 调整Tomcat线程池与JVM配置 #

• 动态调整Tomcat线程参数：
  先解决Redis阻塞问题后，根据负载调整线程数：IO密集型场景下，线程数可设为Pod分配CPU核心数的4-8倍（当前单Pod分配2核，可先调至16-32）；同时增大server.tomcat.accept-count至500-1000，避免1000VUs下请求队列满导致的排队延迟。
• 分析JVM线程栈：用jstack导出线程栈，查看waiting状态线程的具体等待对象（Redis连接、锁或其他资源），精准定位阻塞根源。

3. Kubernetes资源与调度优化 #

• 调整Pod资源分配：当前单Pod分配2000m CPU（2核），m4.4xlarge单节点有16核，可尝试给每个Pod分配4核（4000m CPU），提升单Pod处理能力；内存维持1GB或调整为2GB，确保JVM堆内存充足。
• 扩容Pod副本数：从3个副本扩容至6-8个，分散1000VUs的请求压力，避免单个Pod承载过多流量。
• 优化资源请求/限制：设置resources.requests.cpu=3000m、resources.limits.cpu=4000m，让Kubernetes调度器更合理分配节点资源，避免Pod因节点资源不足被限流。

4. 请求并行化处理 #

若Redis批量操作无法满足需求，可将6次Redis读取改为并行执行（用CompletableFuture），把串行IO耗时转化为并行耗时，进一步降低单请求的IO总时间。

5. 压测与监控细化 #

• 压测期间实时监控：Tomcat线程池的活跃线程数、队列长度，Redis的连接数、QPS，JVM的GC频率（避免频繁GC导致线程停顿）。
• 模拟真实流量：确保压测的请求分布与生产环境一致，避免突发流量引发的队列拥堵。

内容的提问来源于stack exchange，提问作者Umang Desai