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

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，否则连接会被内核拒绝，触发重试争抢。

不复杂但容易忽略