在高并发场景下，如何调整 Connector 的参数以提高吞吐量？

知识点图片

在高并发场景下，调整 Web 服务器（以最常用的 Tomcat 为例，Jetty 和 Undertow 逻辑类似）的 Connector 参数，核心目标是在有限的硬件资源（CPU、内存、带宽）下，最大化并发处理能力，同时避免因资源耗尽导致的系统崩溃。

Connector 的参数调整主要围绕三个核心维度：线程池模型、连接数限制、网络 I/O 模型。

以下是具体的调整策略和参数详解：

1. 理解请求处理的“漏斗模型”

在调整参数前，必须理解请求进入 Tomcat 的流程，这像是一个三级漏斗：

OS TCP 队列 (acceptCount): 操作系统层面的等待队列。
Tomcat 连接池 (maxConnections): Tomcat 维护的活跃 TCP 连接。
Tomcat 线程池 (maxThreads): 真正处理业务逻辑的工作线程。

吞吐量优化的核心就是平衡这三者的关系。

2. 核心参数调整策略

A. 线程池参数 (决定处理速度)

这是最直接影响业务吞吐量的参数。

maxThreads (最大工作线程数)
- 默认值: 通常为 200。
- 调整策略:
  - CPU 密集型任务: 设置为 CPU核数 + 1 或 CPU核数 * 2。线程过多会导致严重的 CPU 上下文切换，反而降低吞吐量。
  - I/O 密集型任务 (大多数 Web 应用，如读写 DB、调用外部 API): 需要更多的线程来掩盖 I/O 等待时间。通常建议设置在 200 ~ 800 之间。
- 注意: 不要盲目设置过大（如 2000+），这会消耗大量内存（每个线程默认 1MB 栈空间）并拖垮 CPU 调度。
minSpareThreads (最小空闲线程数)
- 默认值: 10。
- 调整策略: 在高并发下，建议调大该值（例如 50-100）。这样在流量突增时，不需要临时创建线程，减少响应延迟。

B. 连接数参数 (决定并发容量)

maxConnections (最大连接数)
- 含义: Tomcat 能同时维持的 TCP 连接总数（包括正在处理的和 Keep-Alive 等待的）。
- 默认值: NIO 模式下通常是 10000 (Tomcat 8.5+)。
- 调整策略:
  - 在使用 NIO (Non-blocking I/O) 模式下，一个线程可以管理多个连接，因此这个值可以设置得很高（如 10,000 ~ 20,000）。
  - 只要内存足够，这个值大一点没问题，它决定了服务器能“拿住”多少用户。
acceptCount (等待队列长度)
- 含义: 当 maxConnections 满了之后，操作系统内核层面的 TCP backlog 队列长度。
- 默认值: 100。
- 调整策略:
  - 这是最后一道防线。如果队列满了，新的请求会被直接拒绝（Connection Refused）。
  - 高并发下建议适当调大（如 500 ~ 1000），给突发流量一个缓冲。
  - 警告: 不要设置过大。如果队列太长，用户请求在队列里排队等待超时，体验比直接报错更差。

C. 超时与 Keep-Alive (决定资源回收速度)

在高并发下，快速释放连接比保持长连接更重要。

connectionTimeout (连接超时)
- 含义: 建立连接后等待客户端发送请求体的超时时间。
- 调整策略: 建议设置短一点（如 20000ms 即 20秒），防止慢速攻击或网络差的客户端占用连接。
keepAliveTimeout (长连接超时)
- 含义: HTTP 长连接空闲多久后关闭。
- 调整策略: 高并发场景下，如果客户端请求频率极高，Keep-Alive 有助于减少 TCP 握手开销；但如果连接数吃紧，应减少此值（如 15000ms），强制回收空闲连接给新用户。
maxKeepAliveRequests (长连接最大请求数)
- 含义: 一个长连接复用多少次后强制关闭。
- 调整策略: 默认 100。高并发下可以适当调大（如 200），或者设置为 1（关闭 Keep-Alive，类似短连接），视业务形态而定。通常保持默认或微调即可。

3. I/O 协议模式选择 (`protocol`)

Tomcat 的 Connector 协议模式对吞吐量影响巨大：

BIO (Blocking I/O): 也就是 Http11Protocol。已淘汰。一个连接占用一个线程，并发能力极低。
NIO (Non-blocking I/O): Http11NioProtocol。当前默认且推荐。利用 Java NIO，通过 Selector 多路复用，少量线程即可管理大量连接。适合高并发。
APR (Apache Portable Runtime): 基于 C 语言本地库。性能极佳，特别是处理静态资源和 SSL 加解密时。但部署复杂，需要安装 APR 库。
NIO2 (Async I/O): 适合连接时间非常长且读写操作耗时久的场景。对于普通 Web 应用，NIO 已经足够。

建议: 确保使用的是 NIO 或 NIO2。Spring Boot 2.x/3.x 默认使用 NIO。

4. 示例配置 (Spring Boot `application.yml`)

假设是一个 4核 8G 内存的服务器，处理 I/O 密集型业务：

yaml

server:
  tomcat:
    threads:
      max: 400                # 最大工作线程，不要超过 800
      min-spare: 50           # 预热线程，应对突发流量
    max-connections: 10000    # NIO模式下可以设置较高
    accept-count: 500         # OS 级别的排队队列
    connection-timeout: 20000 # 20秒超时
  # 开启压缩可以以 CPU 换带宽，提高网络吞吐量
  compression:
    enabled: true
    mime-types: text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/json
    min-response-size: 2048

5. 进阶：除了参数还能做什么？

如果调整了上述参数，吞吐量依然上不去，通常瓶颈不在 Connector 参数上，而在：

业务代码阻塞: 检查是否有长时间的数据库查询、外部接口调用（且未设置超时）。
JVM GC 停顿: 频繁的 Full GC 会导致所有线程暂停。需要优化 JVM 堆内存和 GC 算法（如使用 G1 或 ZGC）。
操作系统限制:
- 文件句柄数 (ulimit -n): Linux 默认是 1024，高并发下必须调整为 65535 或更高，否则会报 "Too many open files"。
- TCP 参数: 调整 net.ipv4.tcp_tw_reuse 等内核参数，快速回收 TIME_WAIT 状态的端口。

总结

在高并发场景下调整 Connector 的口诀：

NIO 是基础。
maxConnections 要大（负责抗住并发连接）。
maxThreads 适中（负责处理业务，过多则 CPU 抖动）。
acceptCount 兜底（不要太大，避免无效等待）。
超时时间要短（快速释放资源）。

最重要的一点： 任何参数调整都必须配合 压测 (JMeter/Gatling) 进行验证，没有通用的“最佳配置”，只有适合当前业务场景的配置。

右滑查看面试常问

播面