如何通过哈希算法配置upstream实现加权静态会话绑定，增强业务连续性？

本文共计656个文字，预计阅读时间需要3分钟。

在集群中已有老旧服务器（性能弱、需少承载流量），又有新服务器（性能强、需多承载流量），但需保持会话粘性，可采用分阶段策略：

• 先用 ip_hash 确保所有现有用户始终落在原服务器上，避免登出或状态丢失；
• 在新增节点时，**不直接加入当前 ip_hash upstream**，而是单独配置一个带权重的新 upstream（如 backend_new），配合业务灰度路由（例如通过请求头、URL 路径或 Cookie 标识）将部分新用户导流过去；
• 待老用户自然减少、Session 过期后，再整体切换至新集群，并启用新的 ip_hash 配置。

替代方案：用 hash $cookie_jsessionid 实现应用层会话亲和

当后端应用（如 Java Tomcat、Spring Boot）已生成带签名的 session ID Cookie（如 JSESSIONID），可用通用哈希代替 ip_hash：

• 配置 hash $cookie_jsessionid consistent; —— 一致性哈希能缓解节点增减导致的会话大规模迁移；
• 该方式天然兼容权重：server 192.168.1.10:8080 weight=3; 等仍有效；
• 前提是客户端已携带有效 session Cookie，首次请求可能需配合其他策略（如 fallback 到 least_conn）。

进阶控制：结合 map 指令做条件化哈希路由

对特定 IP 段或 User-Agent，可动态决定是否启用哈希或权重分配：

• 用 map 提取客户端特征（如 $remote_addr 或自定义 header），生成变量 $route_mode；
• 在 location 中根据 $route_mode 选择不同 upstream：一个走 ip_hash（面向内网/固定用户），另一个走加权轮询（面向公网/临时流量）；
• 这种分流不破坏任一算法的语义，也便于灰度验证和故障隔离。

必须避开的误区

以下配置是无效且会被 Nginx 拒绝的：

• upstream backend { ip_hash; server a weight=2; server b weight=1; } → 启动失败，报错 “ip_hash cannot be used with weight”；
• 试图用 hash $remote_addr weight=2 替代 —— Nginx 不支持 hash 指令带 weight 参数；
• 仅靠增加 max_fails/fail_timeout 来“模拟权重” —— 这属于健康检查范畴，不影响正常状态下的调度倾向。