IP Hash是一种工作在负载均衡层的会话粘滞策略。它把客户端IP地址作为哈希输入，经过固定算法得到一个稳定值，再映射到后端Java应用集群中的某一台节点。只要客户端IP不变、集群节点列表不变，该用户的请求就会持续命中同一个Tomcat实例，本地HttpSession因此不会因为负载均衡而丢失。这种方案对Java应用本身几乎无侵入，因为它不改变Session的存储方式，而是通过流量分发规则来保持会话连续性。
理解IP Hash的适用边界，比直接配置更关键。它适合节点数量稳定、用户来源IP分散、Session数据量不大且不强依赖高可用的场景。如果后端节点频繁伸缩，或者用户大量来自同一NAT出口，这个方案会暴露明显的负载不均和会话丢失问题。下面从原理、配置、局限和验证四个层面展开。
一、IP Hash解决的核心问题
Java应用做集群部署时，默认的Session行为是各节点独立保存。用户第一次登录后，Tomcat在内存中创建一个HttpSession对象，并把JSESSIONID通过Cookie返回给浏览器。如果后续请求被负载均衡器分派到另一台节点，那台节点上并没有对应的Session对象，用户就会被当作未登录状态处理。常见的轮询策略表面上让每台机器平均承担请求，但对于依赖登录态的Web应用来说，轮询反而会制造大量无效的跳转和重复登录。
IP Hash的思路很直接：既然Session放在本地，那就想办法让同一用户的请求始终回到同一台机器。它不像分布式Session方案那样需要改造存储层，也不像Cookie粘滞那样依赖浏览器Cookie中嵌入服务器标识。它只依赖一个相对稳定的信息，也就是客户端IP。通过对IP做哈希并取模，可以得到一个固定的后端节点编号。下面是一段简单的Java演示逻辑，说明取模计算的基本过程：
public class IpHashDemo {
public static void main(String[] args) {
String[] servers = {"192.168.10.11:8080", "192.168.10.12:8080"};
String clientIp = "203.0.113.56";
int hash = clientIp.hashCode();
int index = Math.abs(hash) % servers.length;
System.out.println("请求转发至: " + servers[index]);
}
}
实际生产环境中的IP Hash算法不会直接使用String.hashCode()，因为这个方法在不同JVM版本、不同语言实现下可能产生不同结果，而且哈希分布未必均匀。Nginx等负载均衡器内部使用自己的哈希函数，并且在计算时通常还会考虑权重、节点可用状态等因素。不过上述示例足以说明核心思想：哈希函数给出一个相对确定的值，取模后映射到后端节点，从而保持会话连续。
与加权轮询相比，IP Hash牺牲了一部分负载均衡的精细化控制。轮询可以让每台机器严格按权重接收请求，而IP Hash的最终分布取决于客户端IP地址的哈希分布。如果客户端IP网段分布合理，各节点负载通常可以做到大致均衡；但如果某个网段用户特别多，或者哈希函数对某些IP段不够敏感，就可能出现节点冷热不均。
二、Nginx配置与Java应用适配
Nginx是Java集群前面常用的反向代理层，它的upstream模块内置了ip_hash策略。配置非常简单，只需要在upstream块中加上一行ip_hash即可。下面的示例配置了一个包含三台Tomcat节点的集群，其中第三台暂时标记为down状态，不参与转发。
upstream java_cluster {
ip_hash;
server 192.168.10.11:8080 weight=1 max_fails=2 fail_timeout=30s;
server 192.168.10.12:8080 weight=1 max_fails=2 fail_timeout=30s;
server 192.168.10.13:8080 down;
}
server {
listen 80;
location / {
proxy_pass http://java_cluster;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
在Java应用侧，使用IP Hash时不需要引入额外的Session框架。Tomcat仍然按照默认方式在本地内存中创建Session，应用代码也继续使用标准的Servlet API。例如登录成功后，可以用request.getSession().setAttribute("user", user)保存用户信息；后续请求通过request.getSession().getAttribute("user")读取。只要请求回到同一节点，这些代码完全不用修改。
不过，如果应用希望在Session层面做得更规范，可以在Tomcat的web.xml中显式配置会话超时和Cookie属性。下面是一个简单的配置片段，设置Session超时为30分钟：
<session-config>
<session-timeout>30</session-timeout>
</session-config>
需要注意的是，ip_hash策略下，后端节点一旦被标记为不可用，Nginx会把它从哈希环中剔除，请求会重新映射到其他节点。这个过程不是平滑的，原本连到故障节点的用户可能因为重新哈希而丢失Session。因此，节点健康检查和快速恢复非常重要。配置中的max_fails和fail_timeout可以控制探测频率和摘除速度。
三、IP Hash的局限性与常见坑
IP Hash最大的问题在于节点增减时的会话震荡。假设集群原本有三台节点，某天为了扩容加入第四台，哈希取模的分母从3变成4，几乎所有客户端IP的映射结果都会改变。这意味着一次扩容操作可能导致大量用户集体掉线。即便不是主动扩容，某台节点因故障被摘除，同样会触发大范围重新映射。这个问题在生产环境中经常被低估，尤其是电商、在线办公等对登录态敏感的系统。
NAT网络环境也会给IP Hash带来麻烦。很多企业、学校、运营商出口都使用同一个公网IP访问互联网。如果大量用户来自同一个IP，Nginx会把他们全部哈希到同一台后端节点，造成单点压力。此时负载均衡名存实亡，甚至可能因为单台节点负载过高而触发连锁故障。反过来，用户从WiFi切换到移动网络时IP会变化，即使服务端一切正常，Session也会因为哈希结果不同而丢失。
与IP Hash形成对比的是Cookie粘滞和集中式Session共享。Cookie粘滞由负载均衡器在用户浏览器Cookie中写入一个服务器标识，后续请求根据这个标识选择节点，它不依赖客户端IP，因此NAT场景表现更好。而使用Redis存储Session或引入Spring Session后，后端Java节点完全变成无状态，任意请求落在任意节点都能读取到会话数据。这种方案虽然改动量更大，但节点伸缩、故障转移时不会影响用户状态，更适合长期演进的架构。
// Spring Session 搭配 Redis 的一种常见启用方式
@Configuration
@EnableRedisHttpSession
public class SessionConfig {
// 只需声明启用，具体连接由 application.properties 中的 Redis 配置提供
}
选择IP Hash时，至少要做好两类评估：一是当前用户IP的分布是否足够分散，二是后端节点变更频率是否可控。如果两个条件都不满足，建议优先考虑Cookie粘滞或集中式Session存储方案，而不是继续在IP Hash上做补丁。
四、生产环境如何验证与监控
验证IP Hash效果最简单的方式是查看Nginx的upstream_addr字段。在http块中自定义日志格式，把请求来源IP和实际转发到的后端地址记录下来。这样就能直观判断同一IP是否持续命中同一节点。下面的配置定义了一个名为main的日志格式：
log_format main '$remote_addr -> $upstream_addr request_time=$request_time'; access_log /var/log/nginx/access.log main;
观察日志时，可以使用grep或awk对来源IP进行过滤和统计。例如要查看某个客户端IP的转发记录，可以执行grep '203.0.113.56' /var/log/nginx/access.log。如果要统计后端节点接收的请求数量是否均衡，可以用awk提取upstream_addr列后排序计数：
awk '{print $3}' /var/log/nginx/access.log | sort | uniq -c
监控层面需要关注两个指标：节点负载差异和会话丢失率。节点负载差异可以从Nginx日志中统计各upstream_addr的请求比例，如果最大值和最小值相差超过30%，说明哈希分布不够理想，可能需要检查客户端IP段是否过于集中。会话丢失率可以通过Tomcat侧的新建Session数量和失效Session数量的变化趋势来判断。如果某次节点扩容后，短时间内大量用户重新登录，基本可以确定是IP Hash重新映射造成的。
降级方案同样重要。当检测到某个节点即将重启或下线时，可以在Nginx的upstream块中把该节点标记为down，让新请求不再进入。但这并不能挽救已经粘滞在该节点上的老会话。更稳妥的做法是在低峰期进行节点变更，或者先在应用层做好Session集中化改造，使节点变更变成无状态操作。IP Hash可以作为过渡方案，但不应该成为架构的长期依赖。
Java集群会话保持IP Hash负载均衡修改时间：2026-09-22 16:12:37