Nginx原生upstream不支持consistent_hash与weight共存，因一致性哈希是确定性会话绑定，权重被忽略；可用sticky指令实现带权重的会话保持。
Nginx 原生 upstream 模块不支持 consistent_hash + weight 同时生效。这是关键前提：一旦启用 hash $key consistent;，所有 weight 设置将被忽略，请求按一致性哈希结果固定分发，不再考虑权重比例。
为什么 consistent_hash 和 weight 无法共存
Nginx 的 consistent hash 策略本质是“会话绑定型”调度——它把请求 key（如 $remote_addr 或 $request_uri）映射到一个虚拟节点环上，确保相同 key 总落到同一台后端。这个过程是确定性哈希计算，与服务器权重无关。官方文档明确说明：hash 指令（含 consistent）与 weight、max_fails、fail_timeout 等参数互斥。配置中若同时出现，weight 不会报错，但完全不参与调度逻辑。
替代方案：用 sticky 实现带权重的会话保持
若需兼顾“客户端粘性”和“流量按能力分配”，推荐使用 Nginx 官方从 1.5.7 起内置的 sticky 指令（无需第三方模块）。它支持基于 cookie 的会话绑定，并可与 weight 共存：
- 首次请求随机或按权重选择一台后端，生成并返回带签名的 session cookie
- 后端故障时，sticky 支持 fallback 机制（如配合 max_fails），且新会话仍按 weight 分配
示例配置：
upstream backend_cluster {
server 127.0.0.1:8001 weight=3;
server 127.0.0.1:8002 weight=1;
server 127.0.0.1:8003 weight=2;
sticky cookie srv_id expires=1h domain=.example.com path=/ httponly secure;
}
如果必须用 consistent_hash，如何间接引入权重影响
虽不能直接加权，但可通过“调整后端实例数量”模拟权重效果：
- 性能强的机器部署多个应用实例（如 3 个 Flask 进程），分别监听不同端口
- 在 upstream 中为每个实例单独定义 server 行，全部不设 weight（默认为 1）
- 例如：server 127.0.0.1:8001; server 127.0.0.1:8002; server 127.0.0.1:8003; → 相当于权重 3
- 性能弱的机器只部署 1 个实例 → 对应权重 1
这样，consistent_hash 的节点环上，强机器占更多虚拟槽位，自然获得更高请求占比，且仍保持会话一致性。
验证与注意事项
无论选 sticky 还是多实例方式，都需注意：
- reload 前务必运行
nginx -t校验语法；老版本 Nginx（ - consistent_hash 场景下，避免混用 ip_hash 或其他 hash 指令，防止冲突
- Python 应用要读取真实 IP，仍需在 location 中保留：
proxy_set_header X-Real-IP $remote_addr;
