推荐使用Spring Session+Redis统一管理Session，Nginx采用轮询等策略分发请求，所有Java实例共享Redis中的Session数据，实现真正一致、高可用的会话管理。
要让 Nginx 负载均衡和 Java 应用在分布式集群中保持用户会话一致，关键不是只靠 Nginx 单方面“绑定”，而是把 请求分发策略 和 Session 存储机制 配合使用。Nginx 本身不管理 Session，它只负责把请求甩给后端；真正的会话一致性，得由 Session 的存储位置和读取逻辑来保障。
别依赖 ip_hash 做长期会话保障
ip_hash 确实能让同一 IP 的请求总落到同一台 Tomcat 上，看似解决了 Session 问题。但它有硬伤：
- 运营商 NAT 或校园网环境下，几十甚至上百用户共用一个出口 IP，会导致所有请求挤到一台服务器，严重负载不均
- 用户换网络（比如从 WiFi 切到 4G），IP 变了，Session 就断了，登录态丢失
- 集群扩缩容时，哈希映射关系重排，大量用户 Session 失效
所以 ip_hash 更适合作为临时兜底或调试手段，不能作为生产环境的 Session 一致性主方案。
推荐用 Spring Session + Redis 统一管理 Session
这是目前 Java 生态最成熟、稳定、易集成的方案。Spring Session 把原本存在各 Tomcat 内存里的 HttpSession，透明地转存到 Redis 中，并自动完成读写、过期、序列化等操作。
立即学习“Java免费学习笔记（深入）”；
- 所有 Tomcat 实例都连接同一个 Redis 实例（或 Redis 集群），Session 数据天然共享
- Nginx 可放心用轮询（
least_conn或带weight）策略，完全不用关心请求去哪台机器 - 用户登录后，任意一次请求都能从 Redis 中还原出完整 Session，无感知切换
- Redis 支持持久化、主从、哨兵、Cluster，可用性远高于单机内存或数据库
只需在 Spring Boot 项目中引入依赖并加一行注解：@EnableSpringHttpSession，再配好 Redis 连接地址即可生效。
避免踩坑：Cookie 中的 JSESSIONID 必须全局有效
即使用了 Redis，如果 Cookie 的作用域（Domain）或路径（Path）配置不对，浏览器可能不会把 JSESSIONID 发给所有后端节点。
- 确保 Nginx 反向代理时未覆盖或删除
Set-Cookie头（检查是否误加了proxy_cookie_path或proxy_hide_header Set-Cookie） - Java 应用需设置 Cookie Domain 为一级域名，例如
.example.com，这样访问app1.example.com和app2.example.com都能带上同一份 Session ID - 确认 Tomcat 的
sessionCookiePath设为/，避免路径限制导致 Cookie 不携带
补充说明：数据库或本地文件方案为什么不推荐
虽然 MySQL 或文件系统也能存 Session，但它们不适合高频读写的会话场景：
- MySQL 每次请求都要查一次 session 表，IO 压力大，响应延迟高，容易成为瓶颈
- 本地文件（Tomcat 默认）完全隔离，根本无法共享，必须配合复制机制，而复制又带来同步延迟和冲突风险
- Memcached 虽快，但缺乏原生过期策略支持和数据结构灵活性，Redis 在功能、生态和稳定性上全面胜出
不复杂但容易忽略。真正可靠的 Session 一致性，是“Nginx 做好分发，Redis 做好托管，Spring Session 做好衔接”。三者各司其职，才能稳住登录态。
