ip_hash不能与spring session配合构建高可用集群，因其仅为会话粘滞策略，不共享session，导致单点故障、扩缩容中断及违背无状态原则；spring session通过redis集中管理session，支持轮询等健康负载策略。
ip_hash 本身不能和 Spring Session 配合使用来构建高可用集群，它反而会削弱 Spring Session 的价值，甚至带来严重风险。
ip_hash 是一种会话粘滞策略，不是分布式会话方案
ip_hash 是 Nginx 等负载均衡器的调度算法：对客户端 IP 做哈希，固定把同一 IP 的请求转发到同一台后端服务器。它不共享 session，只是“假装” session 存在——实际 session 仍留在单台机器内存里。
这意味着：
- 某台应用服务器宕机，该 IP 段用户全部丢失 session，无法自动恢复
- 扩容或缩容时，IP 哈希映射可能变化，导致大量用户会话中断
- 无法真正实现无状态部署，违背微服务/云原生架构原则
- Spring Session 的核心价值——将 session 存储与容器解耦、集中管理、自动失效/续期——被完全绕过
Spring Session 的正确定位是替代 ip_hash
Spring Session（配合 Redis）解决的正是 ip_hash 想掩盖却没解决的根本问题：session 跨实例不可见。它让所有节点访问同一份 session 数据，因此负载均衡可自由使用 轮询（round-robin）、最少连接（least_conn）等更健康、更公平的策略。
典型配置逻辑是：
- 前端 Nginx 使用默认轮询，不配 ip_hash
- 所有应用节点引入 spring-session-data-redis 依赖
- 配置 Redis 连接（推荐哨兵或集群模式，如 3 主 3 从 + 哨兵，避免单点）
- 通过 @EnableRedisHttpSession 或配置类启用 session 外置
- 无需修改业务代码，HttpServletRequest.getSession() 自动读写 Redis
若必须保留 ip_hash（如历史原因），需注意三点
仅在极特殊过渡场景下临时共存，但必须满足：
- ip_hash 只作为兜底策略：当 Redis 不可用时，至少保证老用户不立即掉线（靠本地内存 session 续命），但要配置短超时（如 maxInactiveInterval=60s）并告警
- Spring Session 仍必须启用：确保 Redis 恢复后 session 能自动同步，避免双写不一致
- 禁用 Tomcat/Jetty 的本地 session 持久化：防止重启后本地 session 覆盖 Redis 中的最新状态
高可用的关键不在 ip_hash，而在存储层与应用层协同
真正提升集群可用性的是：
- Redis 层：采用哨兵或 Cluster 模式（如 3 主 3 从），配置合理的 failover 时间与持久化策略（AOF+fsync everysec）
- 应用层：Spring Session 配置 connection pool（如 Lettuce 连接池）、设置合理 timeout 和重试机制
- 监控层：对 Redis 连通性、session 读写延迟、过期率做实时监控
ip_hash 不是高可用的拼图，而是旧架构的补丁；Spring Session 才是面向分布式的正解。
