session漂移的根本原因是用户请求被轮询分发至不同tomcat导致session不共享；解决方案依次为：①ip_hash会话粘滞（简快但有nat/扩容限制）；②redis共享session（生产首选，需高可用与序列化）；③token无状态认证（面向微服务，需设计刷新与安全机制）。
Session 漂移的根本原因是：用户登录请求被分发到 Tomcat-A，生成了 Session；后续请求被轮询分发到 Tomcat-B，而它没有该 Session，导致鉴权失败、跳转登录页。解决思路是让“同一个用户的请求始终落在同一台后端”，或“让所有后端共享同一份 Session 数据”。下面三种主流方案，按推荐顺序展开：
方案一：用 ip_hash 实现会话粘滞（最简快上线）
在 upstream 块中启用 ip_hash，Nginx 会根据客户端真实 IP 做哈希，固定分配到某台 Tomcat：
- 配置示例：
upstream backend {
ip_hash;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
} - 优点：零代码改动、配置即生效、适合内网管理后台或中小流量场景
- 注意点：必须确保 Nginx 是最前端（否则拿到的是代理 IP）；NAT 环境下多个用户共用公网 IP 会导致误绑定；扩容缩容时部分用户 Session 会失效
方案二：基于 Redis 的 Session 共享（生产环境首选）
把 Session 存到外部 Redis，所有 Tomcat 统一读写，彻底解耦服务器状态：
- Java 项目常用 Spring Session + Redis：引入依赖后，在 application.yml 中配置 Redis 地址，加一个 @EnableSpringHttpSession 注解即可
- Tomcat 原生支持：替换 conf/context.xml 中的 Manager 为 RedisSessionManager（需引入对应 jar）
- 优势：无单点风险、横向扩展自由、Session 生命周期可控（可设过期时间）
- 提醒：需保证 Redis 高可用（主从+哨兵或集群），并注意 Session 对象必须可序列化
方案三：改用无状态认证（面向未来架构）
彻底避开 Session 同步问题，用 Token 替代服务端 Session：
- 登录成功后返回 JWT 或自定义 Token，前端存入 localStorage 或 Cookie（带 HttpOnly）
- 后续每个请求携带 Token，后端校验签名与有效期，无需查 Session 存储
- 适合前后端分离、微服务架构；配合 OAuth2 或 Auth0 可快速落地
- 注意：Token 过期处理、刷新机制、敏感操作二次验证需额外设计
