Nginx权重通过加权轮询实现流量按相对份额（非百分比）分配，weight=0可临时下线节点，未声明则默认为1；调优需结合后端能力、健康检查与会话机制，避免与ip_hash混用。
权重比例本身不能直接“降低”服务器瓶颈，但它能帮你把流量更合理地分摊到不同能力的后端上，避免强机吃不饱、弱机被压垮——这是缓解瓶颈的第一步。
按实际处理能力分配权重
权重不是拍脑袋定的数字，而是对后端真实吞吐、响应延迟、CPU/内存负载的映射。比如一台 8 核机器在压测中稳定支撑 2000 QPS，另一台 4 核只能撑 800 QPS，那它们的权重比可设为 2000:800 ≈ 5:2，而不是简单按核数 2:1 设。
- 先做小流量压测，记录各节点 P95 延迟、错误率、连接数，再反推合理权重区间
- 避免权重悬殊过大（如 1:20），否则低权节点长期空闲，高权节点易成单点热点
- weight=0 可临时摘除故障或维护中的节点，比删配置+reload 更安全
配合健康检查与自动剔除
光设权重不够，还得让 Nginx 主动识别“已变慢”的节点并降权或隔离。max_fails 和 fail_timeout 是基础，但需和权重联动：
- 高权节点一旦连续失败，恢复后会更快重新纳入流量（因权重高，重试阈值更低）
- 建议搭配 proxy_next_upstream error timeout http_503，让超时或服务不可用时自动切到其他节点
- 不要依赖 weight 单独扛住扩容或突发流量，它只是调度策略的一部分
避免权重与会话机制冲突
如果用了 ip_hash 或 sticky session，weight 就基本失效了——请求绑定 IP 后只打固定后端，权重只在该节点下线时起备用作用。
- 有会话状态的应用，优先考虑应用层 session 共享（如 Redis），而非靠 ip_hash 绑定
- 若必须用 ip_hash，就别设 weight；若要用 weight，就改用 least_conn 或纯轮询 + 外部限流
- 权重 + backup 组合更适合灰度发布：新节点 weight=2，老节点 weight=8，backup 放应急兜底机
结合缓存与连接管理进一步减压
权重调优解决的是“怎么分”，而真正降低后端压力，还得让部分请求根本不到后端去：
- 静态资源（JS/CSS/图片）用 expires 或 proxy_cache 缓存，减少 70%+ 的后端请求
- 高频读接口（如商品详情、用户资料）开启 proxy_cache_valid，设置 1–5 分钟缓存
- 开启 proxy_buffering，防止慢客户端拖住后端连接；调整 proxy_buffers 避免缓冲区溢出
