Spring Boot GET接口最大吞吐量优化：支撑30k节点周期性请求

针对你的场景（30k节点周期性同步GET请求、8核32G服务器、Spring Boot 2.6.6 + Tomcat），当前1k/s吞吐量、2秒平均响应的瓶颈可以从以下几个维度优化：

1. 调优Tomcat线程池与连接参数 #

同步IO场景下，线程池是并发能力的核心，当前配置存在优化空间：

• 调整线程池大小：server.tomcat.threads.max当前设为800，对于8核CPU+高IO等待的请求（响应2秒说明大部分时间在等待），可以提升至1600-2400（参考公式：CPU核心数*(1+等待时间/计算时间)），同时设置server.tomcat.threads.min-spare-threads=300，保证有足够空闲线程应对突发请求。注意监控CPU负载，避免线程过多导致上下文切换过载。
• 扩容连接队列：server.tomcat.accept-count默认100，可调至2000-5000，当max-connections耗尽时，请求会进入该队列等待，避免直接被拒绝。同时确认系统文件句柄限制（需提前调至65535以上），避免max-connections=10000的配置无法生效。
• 配置超时回收：添加server.tomcat.connection-timeout=30000（30秒）和server.tomcat.threads.timeout=60000（60秒），及时释放空闲连接与线程，避免资源占用。

2. 消除请求处理链路的阻塞点 #

同步GET的响应时间主要由后端依赖决定，需针对性优化：

• 引入缓存：如果接口数据具有一定时效性，用本地缓存（如Caffeine）或分布式缓存（如Redis）缓存结果，避免每次请求都穿透到DB或下游服务。例如用Caffeine配置：

  @Bean
  public Cache<String, YourData> dataCache() {
      return Caffeine.newBuilder()
          .expireAfterWrite(5, TimeUnit.MINUTES)
          .maximumSize(10000)
          .build();
  }
  

• 优化数据库访问：若依赖DB，优先优化SQL（添加索引、避免全表扫描），调整HikariCP连接池参数spring.datasource.hikari.maximum-pool-size=80（匹配DB的最大连接数限制），避免连接池成为瓶颈。
• 简化处理逻辑：移除接口中的冗余日志、对象转换、非必要计算，尽量让请求线程快速完成处理。

3. 系统与JVM层面优化 #

充分利用硬件资源，减少底层瓶颈：

• 调整JVM参数：设置-Xms16G -Xmx16G（分配总内存的一半给堆内存），启用G1垃圾收集器-XX:+UseG1GC，减少GC停顿对并发的影响；同时配置-XX:MaxMetaspaceSize=512M避免元空间溢出。
• 提升系统文件句柄限制：修改Linux系统的/etc/security/limits.conf，添加：

  * soft nofile 65535
  * hard nofile 65535
  

  重启后生效，保证Tomcat能支撑10000+的连接数。

4. 架构层面扩容 #

若单实例优化后仍无法满足需求，考虑：

• 水平扩展：部署多台Spring Boot实例，通过Nginx或云负载均衡器分发请求，将30k节点的流量分散到多个实例，整体吞吐量线性提升。
• 请求削峰：让不同节点的周期性请求错开时间（比如给每个节点分配随机偏移量），避免瞬时并发集中冲击服务器。
• CDN加速：对于静态/准静态数据，将内容推送至CDN，让节点直接从CDN获取，彻底绕过应用服务器，极大提升吞吐量。

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