Nginx多进程架构通过操作系统协同实现近似均匀连接分发，核心是避免争抢、减少干扰、利用内核能力；需匹配CPU核心数设worker_processes，启用accept_mutex防惊群，高并发下推荐reuseport由内核哈希分发，并配置worker_cpu_affinity提升缓存命中率。
Worker 进程数量要匹配 CPU 核心数
每个 Worker 是独立进程，绑定一个 CPU 核心运行最高效：
- worker_processes auto; 是推荐写法，自动设为逻辑 CPU 核心数（如 4 核服务器即启 4 个 Worker）
- 设得过多（比如 16 个 Worker 跑在 4 核机器上），会引发频繁上下文切换，反而拖慢性能
- 设得过少（比如只设 1），无法并行处理，CPU 利用率低，成为瓶颈
accept_mutex 控制连接争抢
多个 Worker 同时监听同一端口时，若不加协调，会出现“惊群效应”——所有 Worker 都被唤醒去 accept()，但只有一个成功，其余空转浪费资源：
- 默认开启 accept_mutex on;，让 Worker 排队获取新连接，提升公平性
- 这不是负载均衡器，但它能防止连接集中砸向某一个 Worker，是基础保障
- 在低并发或旧内核环境下仍有效，但高并发场景建议配合 reuseport 使用
reuseport 让内核直接分发连接
Linux 3.9+ 支持 SO_REUSEPORT，Nginx ≥ 1.9.1 可启用，这是现代高并发部署的核心优化：
- 每个 Worker 绑定同一个端口的独立 socket，内核按哈希（源IP+端口+目标IP+端口）把新连接直接派给某个 Worker
- 完全绕过 accept_mutex 争抢，连接分发更均匀、延迟更低、吞吐更高
- 配置只需一行：reuseport on;（放在 events 块中），需确认内核版本与 Nginx 版本支持
CPU 亲和性减少缓存抖动
让每个 Worker 固定运行在指定 CPU 核心上，可提升 L1/L2 缓存命中率，降低跨核通信开销：
- 配置示例：worker_cpu_affinity 0001 0010 0100 1000;（4 核机器）
- 对应关系清晰：第一个 Worker 绑定 CPU0，第二个绑定 CPU1，依此类推
- 结合 worker_processes auto 使用时，需确保 affinity 位数与实际核心数一致
