Nginx多进程架构通过worker进程与CPU核心绑定实现硬件级负载均衡，而非后端服务器负载均衡；默认worker_processes auto配合worker_cpu_affinity auto可自动匹配物理核心，结合网卡多队列、RPS及NUMA优化，确保网络中断、软中断与worker同核运行，提升并发性能。
Nginx 多进程架构本身不执行“对后端服务器的负载均衡”，但它通过合理调度 worker 进程，实现对多核 CPU 硬件资源本身的负载平衡——这是高并发场景下性能发挥的基础。关键不在“分发请求给后端”，而在“让每个 CPU 核心高效、专注地处理网络请求”。
多进程如何匹配多核 CPU
Nginx 默认采用 worker_processes auto;，会自动读取系统 CPU 核心数（不含超线程逻辑核），启动对应数量的 worker 进程。每个 worker 独立运行、互不阻塞，天然适配多核并行：
- 每个 worker 绑定到一个物理 CPU 核（通过
worker_cpu_affinity或内核SO_REUSEPORT协同） - 避免单核过载、其他核空闲的“木桶效应”
- 减少跨核缓存失效（cache line bouncing）和上下文切换开销
建议配置：
worker_processes auto;-
worker_cpu_affinity auto;（Nginx 1.9+ 支持，自动绑定各 worker 到不同核心） - 若需手动控制（如 NUMA 架构），可用位掩码：
worker_cpu_affinity 0001 0010 0100 1000;（4 核机器，每个 worker 独占 1 核）
网络中断与 CPU 的协同分发
光靠 worker 绑定不够——如果网卡中断全打到一个 CPU，后续 worker 仍会争抢。需让网络软中断也分散：
- 启用网卡多队列：
ethtool -L eth0 combined N（N = 物理核心数） - 开启 RPS（Receive Packet Steering）：向
/sys/class/net/eth0/queues/rx-0/rps_cpus写入十六进制掩码（如 8 核写ff） - 验证：
watch -n 1 'cat /proc/softirqs | grep NET_RX'，各 CPU 的计数应均匀增长
这样，从网卡收包 → 软中断处理 → Nginx worker 接收连接，整条链路都落在同一组匹配的 CPU 上。
NUMA 架构下的资源局部性优化
在双路或多路服务器中，CPU 和本地内存绑定。跨 NUMA 节点访问内存延迟可翻倍：
- 先用
lscpu和numactl --hardware查清拓扑 - 将
worker_processes设为单 NUMA 节点的物理核心数（如每节点 16 核，就设16） - 启动时用
numactl限定 CPU 与内存范围：numactl --cpunodebind=0 --membind=0 /usr/sbin/nginx
验证方式：numastat -p $(pgrep nginx) 中 local_node 应 >95%，foreign 接近 0。
负载策略选择也影响 CPU 利用率
不同 upstream 算法计算开销差异明显，间接决定 worker 的 CPU 占用：
- 轮询（round-robin）：仅维护一个计数器，开销最低，适合大多数场景
- ip_hash / hash $request_uri：需哈希计算，万级 QPS 下可能吃掉 worker 10%~20% CPU
- least_conn：依赖共享内存锁读取各节点连接数，节点多（>32）、核数高（>16）时易引发锁争用，推高 sys CPU
实操建议：压测时用 top -H -p $(pgrep nginx) 观察各 worker 线程的 %CPU 和上下文切换次数（cs 列），优先选轮询；确需会话保持再用 ip_hash，并确保后端节点数稳定。
不复杂但容易忽略
