在ingress-nginx中结合upstream-hash-by实现负载均匀分布与会话粘性

核心矛盾说明 #

直接将upstream-hash-by（一致性哈希）与轮询/最少连接策略结合是不可行的——前者依赖固定的哈希映射保证会话粘性，后者是动态根据节点状态或顺序选节点，两者调度逻辑互斥，无法同时生效。

你遇到的自定义请求头哈希后负载不均，本质原因通常是：请求头的取值分布本身不均衡（比如部分值出现频率极高），导致哈希映射后大量请求集中到少数后端Pod。

可行的折中方案 #

以下是生产环境中常用的平衡粘性与负载均匀性的方案：

1. 一致性哈希+虚拟节点（Virtual Nodes） #

这是解决一致性哈希分布不均的经典方案，通过给每个真实后端Pod分配多个“虚拟节点”，让哈希环上的节点分布更密集，从而让请求映射更均匀，同时保留会话粘性。

• 实现方式：如果使用第三方Nginx模块（如ngx_http_upstream_consistent_hash），可直接配置虚拟节点数量；原生Nginx可通过自定义哈希键模拟，比如将Pod标识与序号拼接生成多个虚拟条目，再基于扩展后的哈希环做映射。
• 效果：既保证同一请求头的请求落到同一真实Pod，又能大幅缓解负载倾斜问题。

2. 分层调度策略 #

将调度分为两层：

• 第一层：用一致性哈希将请求映射到一个Pod分组（比如2-3个Pod组成的小集群），保证会话在分组内的粘性；
• 第二层：在分组内部使用轮询或最少连接策略分发请求，实现组内负载均匀。
• 示例（Nginx配置）：

  split_clients "$http_x_custom_header" $group {
    33%    group1;
    33%    group2;
    *      group3;
  }
  
  upstream group1 {
    server pod1:80;
    server pod2:80;
    least_conn;
  }
  
  upstream group2 {
    server pod3:80;
    server pod4:80;
    least_conn;
  }
  
  server {
    location / {
      proxy_pass http://$group;
    }
  }
  

3. 粘性兜底+动态负载均衡 #

优先用一致性哈希选择节点，当选中的节点负载过高（如连接数超过阈值）或不健康时，自动 fallback 到最少连接/轮询的节点：

• 实现方式：比如Envoy的ring_hash负载均衡器支持配置fallback_policy: LEAST_REQUEST，既保留大部分会话粘性，又避免个别Pod过载；Nginx可通过自定义Lua脚本（OpenResty）实现负载统计与兜底逻辑。

4. 优化哈希键生成逻辑 #

如果必须用单一自定义请求头做哈希，可通过混合字段优化分布：

• 将自定义请求头与一个稳定且均匀分布的字段拼接（如客户端IP后两位、请求ID的哈希值），作为最终哈希键：

  upstream backend {
    hash "$http_x_custom_header$remote_addr";
    server pod1:80;
    server pod2:80;
  }
  

• 注意：额外字段需保证同一客户端的请求稳定，否则会破坏会话粘性。

针对自定义请求头哈希不均的专项优化 #

• 检查请求头分布：先统计请求头取值的频率，对高频值（如热门用户ID）单独处理——比如将高频值拆分到多个虚拟节点，或直接对高频值用轮询分发，其余值用哈希。
• 增加虚拟节点数量：虚拟节点越多，哈希映射的均匀性越好，能有效缓解因请求头值分布不均导致的负载倾斜。

可行性总结 #

虽然无法同时直接使用一致性哈希与轮询/最少连接，但通过上述折中方案，完全可以在保留会话粘性的核心需求下，实现负载的均匀分布，这些方案在电商、社交等需要粘性的生产场景中已被广泛验证。

内容的提问来源于stack exchange，提问作者djGowda