加权轮询是适配异构后端的关键调度策略，需基于实测qps等性能指标设权重（如5:2:3），配合health_check实现故障剔除与权重再平衡，并通过worker_processes auto、worker_cpu_affinity等系统级配置释放多核能力。
加权轮询本身不直接提升多核 CPU 利用率，但它是适配多核异构后端的关键调度策略。真正释放多核处理能力，靠的是让加权轮询和系统层、Nginx 运行时协同工作。
匹配后端服务器真实性能差异
权重不是拍脑袋定的。CPU 核心数、内存带宽、磁盘 I/O 能力都会影响吞吐上限。比如一台 16 核服务器和一台 4 核服务器，单纯按 4:1 设权重可能高估后者处理能力——实际测试中前者 QPS 可能是后者的 5.2 倍。建议用压测工具（如 wrk 或 hey）在相同请求路径下分别打满单机，记录稳定 RPS，再按比例折算权重。
- 避免整数倍粗略估算，例如“8核 vs 2核 → weight=4”容易导致小核机器过载
- 权重总和不必为 100，只需保持比例关系，Nginx 内部自动归一化
- 动态扩容时，及时更新权重，不要长期沿用旧配置
减少加权调度本身的 CPU 开销
加权轮询比普通轮询多一次累加与模运算，但在万级 RPS 下仍属轻量。真正吃 CPU 的是 hash 类算法（如 ip_hash），而加权轮询无哈希计算，worker 进程开销通常低于 2%。不过要注意两点：
- 禁用不必要的指令：比如在 upstream 块里混用 ip_hash 和 weight 会触发冗余判断逻辑
- 避免高频重载配置：每次 reload 都会重建权重数组，高频率操作会抖动 worker 调度状态
- 用 least_conn 替代加权轮询，仅当后端连接数差异显著且请求生命周期长（如 WebSocket、长轮询）
打通从接入到承载的全链路
加权轮询只是“分发”环节，多核能力能否发挥，取决于前面是否接得住、后面是否扛得稳：
- worker_processes auto; —— 确保 Nginx worker 数量匹配物理 CPU 核数
- worker_cpu_affinity auto; —— 让每个 worker 绑定独立核心，减少上下文切换
- 调大 worker_rlimit_nofile 和系统级 ulimit -n，防止文件描述符耗尽卡住新连接
- 后端服务自身也要开启多线程或多进程模型（如 Gunicorn workers 数 ≥ CPU 核数），否则加权再合理也喂不饱空闲核心
配合健康检查与故障隔离
加权轮询不会自动规避慢节点。若某台高权重服务器因 GC 或锁竞争响应变慢，它仍会持续接收大量请求，拖垮整体吞吐。必须启用主动健康检查：
- 配置 max_fails=2 fail_timeout=15s，快速剔除异常节点
- 搭配 slow_start=30s，让恢复后的高权重服务器逐步承接流量，避免雪崩
- 对关键业务做流量染色或 upstream 分组，把高权重机器单独划入高性能池，避免被低优先级请求挤占资源
