Nginx Worker 进程的“动态负载均衡”实为系统级被动均衡，需通过 worker_processes auto、reuseport on、accept_mutex off（旧版本）、worker_cpu_affinity auto 及足够 worker_connections 等配置协同内核实现近似均匀分担。
Nginx 的 Worker 进程本身不支持动态负载权重或实时调度调整，所谓“Worker 动态负载均衡”并不是 Nginx 提供的功能，而是通过合理配置与内核协同，让多个 Worker 在运行时自然、近似均匀地分担连接请求。这种均衡不是靠算法动态分配，而是靠系统级机制实现的被动均衡。
下面从实际可操作的角度说明关键要点：
如何让 Worker 进程在运行中更均衡地承接请求
设对进程数
worker_processes auto;是最稳妥的选择，它会自动匹配物理 CPU 核心数（非逻辑线程数），避免因超配导致上下文切换开销上升。容器环境需按 cgroup 限额计算真实可用核数：cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us÷cpu.cfs_period_us-
启用内核级连接分发（推荐）
在events块中开启：use epoll; reuseport on; # Linux ≥3.9，Nginx ≥1.9.1 multi_accept on;
reuseport让每个 Worker 绑定独立 socket，内核按四元组哈希直接把新连接派发到某个 Worker，绕过 accept 竞争，效果比accept_mutex更均衡、延迟更低。 关闭 accept 锁（旧版本需显式关）
若使用较老 Nginx（<1.11.3），需明确设置：accept_mutex off;
否则所有 Worker 串行抢锁，容易出现“一个忙死、几个闲死”的现象。绑定 CPU 亲和性，减少干扰
配置worker_cpu_affinity auto;（Nginx ≥1.9.10），或手动指定掩码：worker_cpu_affinity 0001 0010 0100 1000;
确保每个 Worker 固定运行在不同物理核上，独占缓存，提升吞吐稳定性。保证单 Worker 处理能力充足
worker_connections 65535;要设够大，否则即使开了 8 个 Worker，总并发卡在 8×1024 = 8192，多数 Worker 实际空转。
怎么验证是否真均衡
查看 Worker 所在 CPU：
ps -eo pid,comm,psr | grep 'nginx: worker'
确认每个 Worker 分布在不同 CPU ID 上。观察各核负载是否接近：
top -1→ 按1显示各 CPU 使用率，理想状态是各核 %us 波动范围相近（如都在 65%～82%）。NUMA 架构下检查内存访问效率：
numastat -p $(pgrep nginx | head -1)→ 关注numa_miss是否持续升高，高则说明跨节点访问频繁，需调整worker_cpu_affinity或启动参数。
不复杂但容易忽略
