Nginx 中 worker_processes 如何处理高并发连接争抢-Nginx-PHP中文网

nginx 的 worker_processes 应匹配物理核心数并绑定 cpu，避免过小导致串行瓶颈、过大引发惊群与上下文切换开销；需配合 accept_mutex、multi_accept、keepalive 限制及系统级资源兜底，方能消除连接争抢。

nginx 中 worker_processes 如何处理高并发连接争抢

Nginx 中 worker_processes 本身不直接“处理”争抢，而是通过合理设置来预防争抢发生。真正的连接争抢（如惊群、锁竞争、CPU 调度混乱）源于进程数与硬件、负载、内核机制不匹配。关键不是让 worker “抢得更快”，而是让它们“分得更稳、干得更专”。

worker_processes 设置不当会加剧争抢

设得太小（如固定为 1）：所有连接挤在一个进程里，单核打满，排队阻塞，看似没争抢，实则是串行瓶颈；
设得过大（如 32 核机器配 64 个 worker）：进程频繁切换、共享监听套接字触发惊群、内存和锁开销上升，CPU 时间片浪费明显；
不绑定 CPU（缺 worker_cpu_affinity）：worker 在不同核心间跳转，L1/L2 缓存反复失效，TLS 加解密等 CPU 密集操作性能骤降。

高并发下靠协同机制消解争抢

worker_processes 必须配合以下配置，才能真正规避资源争抢：

自动适配 + 显式约束
用 worker_processes auto; 让 Nginx 读取逻辑核数，但在容器或云环境需手动限定上限（如 worker_processes 8;），避免被虚报的 vCPU 数误导。
CPU 亲和强制隔离
配合 worker_cpu_affinity auto;（或显式掩码），确保每个 worker 独占一个物理核心。验证方式：
```
ps -eo pid,psr,comm | grep 'nginx: worker' | sort -k2,2n
```
输出中每个 PID 应对应唯一 PSR（CPU 号），无重复。

Nginx Hosting
通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载
accept_mutex + multi_accept 控制分发节奏
默认开启的 accept_mutex on; 让 worker 串行获取新连接，防惊群；再启用 multi_accept on;，使抢到锁的 worker 一次性收多个就绪连接，减少事件循环空转。
连接生命周期必须收紧
即使 worker 数合理，若 keepalive_timeout 过长（如 75s）、keepalive_requests 不设限，少量慢连接会长期占槽，挤压新请求——这本质是“隐性争抢”。建议：
- API 类服务：keepalive_timeout 30s; keepalive_requests 500;
- HTTP/2 场景：http2_idle_timeout 25s;（比 keepalive 更短）
系统级资源必须兜底
worker_processes × worker_connections 要 ≤ 系统文件描述符上限：
```
worker_rlimit_nofile 65535;
events {
    worker_connections 8192;
    use epoll;
    multi_accept on;
}
```
并确保启动前执行 ulimit -n 65535，否则连接会被内核拒绝，触发重试争抢。

不复杂但容易忽略