Spring Boot Webflux在CPU达99.9%时仍能处理更多流量的原因解析

你遇到的现象核心在于CPU饱和点是网络IO处理的瓶颈，而非业务逻辑的处理上限，结合WebFlux底层Netty机制、HTTP/2特性以及操作系统的网络队列逻辑，具体原因如下：

• CPU消耗集中在网络层而非业务逻辑
  你的端点无IO或CPU密集计算，CPU消耗几乎全部来自Netty处理HTTP/2的网络通信：包括帧的解析/编码、HTTP/2多路复用管理、流量控制、缓冲区拷贝与调度等。当TPS达到10K时，Netty的事件循环线程（通常数量等于CPU核心数）已完全被这些网络任务占满，CPU使用率拉满至99.9%。

• 请求队列的缓冲机制
  操作系统套接字接收队列（backlog）、Netty自身任务队列会起到缓冲作用。当TPS提升至12K时，超出服务器即时处理能力的请求会被暂存到这些队列中，等待空闲的事件循环线程处理。只要队列未溢出，这些请求最终都会被处理完成，客户端会收到成功响应，只是请求处理延迟会明显上升。

• HTTP/2的多路复用与流量控制
  你使用了两个HTTP/2客户端连接，HTTP/2支持在单个连接上多路复用多个请求。当服务器CPU满负荷时，Netty会通过HTTP/2流量控制机制通知客户端放缓请求发送速度，避免队列溢出。这种协同下，客户端推送的12K TPS会被“削峰”，服务器按自身最大处理能力（约10K）逐步处理队列中的请求，最终所有请求都能完成。

• CPU使用率的统计特性
  99.9%的CPU使用率已意味着系统几乎无空闲CPU时间，再提升TPS不会让CPU使用率继续上升——因为已无可利用的空闲周期。但这并不代表服务器无法处理更多请求，只是这些请求需要排队等待，CPU始终保持满负荷状态处理队列中的任务。

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