权重分配不实现请求优先级，而是按后端承载力静态分配流量；需结合路径分流、独立upstream和策略组合才能实现请求级优先调度。
权重分配本身不直接实现“请求优先级”，而是通过让更强的后端承担更多流量，间接支撑高优业务的稳定运行。它解决的是“哪台机器该多干活”的问题，不是“哪个请求该先处理”。真正做请求级优先调度，得靠路径分流+独立 upstream + 策略组合。
权重是服务器能力的静态映射
weight 值反映的是后端节点的相对承载力，比如一台 16C32G 的机器和一台 4C8G 的机器，合理权重可设为 4 和 1；若压测得出吞吐量比是 1500 req/s : 500 req/s，就设为 3 和 1。它不感知实时负载，只按预设比例分发——所以数值要基于实测数据，不能拍脑袋写个 weight=10。
- 权重必须写在 upstream 的 server 行里，例如：server 192.168.1.10:8080 weight=4;
- weight 只接受正整数，比例才有效：3:1 和 30:10 效果一致，但后者更利于微调
- 避免用过小的数（如 1 和 2），容易放大误差；推荐统一放大倍数，比如 10:4:2
单靠权重无法应对故障或冷启动
设了 weight=5 的机器如果卡死，照样会收请求——除非配上健康检查。Nginx 默认只轮询，不自动避障。
- 每台 server 加上 max_fails=2 fail_timeout=10s：连续失败两次，暂停 10 秒再试探
- 新节点上线时加 slow_start=60s：流量从 0 开始线性爬升，防冷启动打满
- 临时下线用 weight=0，不触发健康检查，适合维护窗口期
真要实现请求级优先，得靠路径分流
想让 /api/admin/ 这类关键接口走高性能集群，而 /api/report/ 这类耗时任务走低配集群，就不能只靠 server 级 weight，得把流量在入口就拆开。
- 定义两个 upstream：backend_high（least_conn + 高配节点）和 backend_low（weight=2:1 + 限流）
- 用 location 匹配路径：location /api/admin/ { proxy_pass http://backend_high; }
- 配合 limit_req 控制低优接口速率，避免挤占带宽或连接数
别混淆权重与会话保持策略
ip_hash、hash $request_uri 这些策略和 weight 是互斥的。一旦启用 ip_hash，所有来自同一 IP 的请求都会固定落到某台机器，weight 就失效了。
- 需要会话保持时，优先考虑后端统一存 session（如 Redis），而非依赖 ip_hash
- 缓存类接口可用 hash $request_uri，但此时 server 行不能写 weight
- 长连接多、响应时间差异大的场景，least_conn 比纯 weight 更稳
