加权轮询优化关键在于权重精准、调度稳定、系统协同：需实测单机RPS定权重（如52:21:33），避免核数换算；禁混用ip_hash与weight；长连接优先least_conn；绑定CPU、调大连接数；启用健康检查实现动态权重。
加权轮询本身不是性能瓶颈，但百万并发下若配置失当，会放大调度偏差、掩盖后端真实负载，甚至引发雪崩。优化关键不在“轮”得更快，而在让权重更准、调度更稳、系统更协同。
用实测 QPS 定权重，别信核数比
权重不是按 CPU 核心数简单换算（比如 16 核 ÷ 4 核 = weight 4）。实际吞吐受内存带宽、磁盘 I/O、JVM GC、数据库连接池等多因素影响。必须在相同路径、相同压测模型下，分别对每台后端做单机满载测试（如用 wrk -t4 -c1000 -d30s http://ip:port/api），记录稳定 RPS 值，再按比例设 weight。
- 例如测得 A 机 RPS=5200、B 机 RPS=2100、C 机 RPS=3300 → 权重可设为 52:21:33（无需归一或凑整）
- 避免长期沿用旧权重，扩容或升级后端后必须重测更新
- weight 总和无意义，Nginx 内部自动归一化，只看比例关系
减少调度层干扰，保持轻量执行
加权轮询的 CPU 开销本身很低（万级 RPS 下 worker 占用通常＜2%），但错误配置会引入冗余逻辑：
- 不要在同一个 upstream 块里混用 ip_hash 和 weight，会触发额外判断分支
- 避免高频 reload：每次重载都会重建权重数组，造成短暂抖动；改用 nginx -s reload 配合平滑过渡，非必要不频繁操作
- 长连接类服务（如 WebSocket、gRPC 流式接口）优先考虑 least_conn，它比加权轮询更能反映实时承载压力
绑定 CPU + 调大连接容量，释放多核真实能力
加权轮询只是分发策略，真正跑满多核，靠的是 Nginx 运行时与系统深度配合：
- worker_processes auto; —— 确保 worker 数量匹配物理核心数
- worker_cpu_affinity auto; —— 让每个 worker 绑定独占核心，减少上下文切换
- worker_connections 65535; 且同步调高系统级限制：ulimit -n 100000、fs.file-max = 2000000
- 后端服务自身也要配够并发模型，比如 Gunicorn 的 workers ≥ CPU 核数，否则 Nginx 分得再合理，请求也卡在应用排队队列里
加健康检查，让权重动态可信
静态权重无法应对运行时劣化。某台高权重机器因慢 SQL 或 Full GC 响应延迟飙升，仍会持续接收大量请求，拖垮整体 SLA。
- 启用主动健康检查：health_check interval=5s fails=2 passes=2;
- 配置快速剔除：max_fails=2 fail_timeout=15s;
- 恢复后防雪崩：slow_start=30s;，让高权重节点逐步承接流量
- 配合日志监控权重分配日志（如 $upstream_addr 变化频率），及时发现倾斜异常
