least_conn仅依据后端活跃连接数调度，不感知cpu/内存；worker_cpu_affinity绑定nginx worker进程到cpu核心以提升调度实时性，二者协同优化高并发性能。
Nginx 的 least_conn 算法本身不感知 CPU、内存等资源指标，它只依据每个 upstream server 的实时活跃连接数（含 keepalive 空闲连接）做调度决策。而 CPU 亲和性（worker_cpu_affinity）是 Nginx 自身 worker 进程与物理 CPU 核心的绑定机制，属于系统级性能优化手段，并不直接影响 least_conn 的选节点逻辑。
但二者在高并发集群中协同工作时，能显著提升整体负载分发的稳定性和响应效率——前者管“往哪台后端发”，后者管“Nginx 自己在哪跑得更稳”。所以不是“根据后端 CPU 亲和性去调 Nginx”，而是：让 Nginx 的多进程高效运行，从而更准确、低延迟地执行 least_conn 调度。
以下是你真正需要关注的配置要点：
确保 Nginx worker 进程不被频繁迁移
Linux 默认调度器可能把 worker 进程在不同核心间切换，导致 L1/L2 缓存失效、TLB 刷新、上下文切换增多，间接拖慢连接统计、健康检查响应和 upstream 选择速度。这会让 least_conn 的“实时性”打折扣。
推荐写法（Nginx ≥ 1.9.10）： worker_processes auto;
worker_cpu_affinity auto;手动绑定示例（8 核 CPU，启 8 个 worker）： worker_processes 8;
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;
验证是否绑定成功
运行后检查任意 worker 进程的 CPU 绑定情况：
taskset -cp $(pgrep -f "nginx: worker" | head -1) # 或查看 /proc/<pid>/status 中的 Cpus_allowed_list</pid>
别混淆：后端服务器的 CPU 亲和性 ≠ Nginx 的 CPU 亲和性
- Nginx 的
worker_cpu_affinity只控制 Nginx 自身 worker 进程在哪几个 CPU 核上运行； - 后端服务（如 Java 应用、Go 微服务）是否启用 CPU 绑定，需在其自身启动参数中配置（如 JVM 的
-XX:+UseParallelGC -XX:ActiveProcessorCount=4或taskset启动），这会影响其处理单个连接的实际耗时，从而间接影响 least_conn 的效果（比如某后端因 CPU 抢占严重，响应变慢、连接堆积，least_conn 就会自然避开它）。
配合 least_conn 发挥最大价值的关键项
CPU 亲和性只是基础，要让 least_conn 真正反映后端真实负载，必须同步配齐：
- 每个
server行配置max_fails=2 fail_timeout=15s，配合被动健康检查； -
proxy_next_upstream error timeout http_500 http_502;，确保失败请求及时重试； -
upstream块内启用keepalive 32;，并确保后端开启长连接支持； - 避免与
ip_hash、hash $arg_id等哈希策略混用，否则 least_conn 不生效。
不复杂但容易忽略。
