ip_hash不能实现Session同步，仅通过IP哈希固定请求到同一服务器以减少Redis读写；真正无感同步依赖Redis集中存储Session数据，两者互补：ip_hash降压，Redis兜底保障故障连续性。
ip_hash 本身不能实现 Session 同步，它只是把同一 IP 的请求固定打到同一台后端服务器上，让 Session 看似“不丢失”。真正实现跨节点无感同步的，是 Redis——它负责把 Session 数据集中存储，所有节点都读写同一份数据。ip_hash 和 Redis 是互补关系：前者降低对 Redis 的读写压力，后者兜底保障故障时的会话连续性。
ip_hash 的作用与局限
nginx 的 ip_hash 是一种客户端亲和（Sticky）策略，根据用户 IP 做哈希运算，将请求长期绑定到某台 Tomcat 或 Spring Boot 实例。这样，只要该实例在线，Session 就始终在本地内存中读写，无需频繁访问 Redis。
- 配置简单，不改代码，适合快速上线
- 能缓解 Redis 的 QPS 压力，尤其在中小流量场景下效果明显
- 但一旦绑定的节点宕机或重启，用户会话立即中断（因为本地 Session 消失，且未提前落库）
- IP 地址可能被 NAT 或代理池复用，导致多个真实用户被哈希到同一节点，引发负载倾斜
Redis 才是无感同步的核心
要真正实现“跨节点无感”，必须把 Session 的创建、读取、更新、失效全部交由 Redis 统一管理。无论请求落到哪台机器，都通过同一个 key（如 spring:session:sessions:{sessionId}）去 Redis 查找或写入。
- Spring Boot 项目只需引入
spring-session-data-redis依赖，并加@EnableRedisHttpSession注解 - 配置项如
spring.session.store-type=redis、spring.redis.host、spring.session.timeout=1800即可生效 - Session ID 仍由 Cookie 传递（JSESSIONID 或自定义 cookie name），但底层存储已脱离 JVM 内存
- 即使某台服务挂掉，新请求被 nginx 分发到其他节点，也能从 Redis 中还原完整会话状态，用户无感知
两者配合的关键设计点
单纯开启 ip_hash + Redis 并不等于“高可用”，还需注意几个衔接细节：
-
Session 创建时机要统一：避免部分请求走本地内存 Session（如未配置 Filter 链），所有 HTTP 请求必须经过 Spring Session 的
SessionRepositoryFilter -
ip_hash 不应作为唯一保障：生产环境建议关闭 sticky 会话的强依赖，比如用
least_conn或round_robin+ Redis，更利于弹性扩缩容 - Redis 连接必须高可用：使用 Redis Sentinel 或 Redis Cluster，避免单点故障导致全站 Session 不可用
-
Session ID 的 Cookie 属性需合理设置：如
http-only=true、secure=true（HTTPS 下）、max-age与后端 timeout 匹配
验证是否真正“无感”
最直接的测试方式是模拟节点故障：
- 用浏览器登录，确认能拿到有效 Session ID
- 手动停掉当前处理请求的后端服务（如 kill -9 java 进程）
- 刷新页面或发起新请求，观察是否仍保持登录态、用户信息是否完整
- 用
redis-cli查看KEYS "spring:session:*"，确认 session key 存在且 TTL 正常递减
