Java应用在Nginx集群中会话保持与Cookie共享需分层处理：优先用sticky cookie实现无侵入路由；次选用$cookie_jsessionid一致性哈希；中大型系统应迁至Redis统一存储，避免硬绑定瓶颈。
Java 应用在 Nginx 负载均衡集群下，会话保持（Session Persistence）和 Cookie 共享本质是两个关联但目标不同的问题：前者确保用户请求持续打到同一台后端（解决“登录后跳转又要求重登”），后者指多个服务实例能读写同一份会话数据（解决“购物车只在某台服务器上有”）。实际部署中，推荐按业务规模和改造能力分层处理——不强求一步到位，但要避免混用冲突方案。
优先用 sticky cookie 实现无侵入会话路由
这是 Java 部署最常用、见效最快的方案，尤其适合 Spring Boot + Tomcat 默认 Session 存储模式（内存型）的场景：
- Nginx 编译安装 nginx-sticky-module-ng 模块（开源免费，非官方但稳定），配置示例：
<!-- upstream 块内 -->
upstream backend {
sticky cookie srv_id expires=1h domain=.yourdomain.com path=/;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
}
- 首次请求无 cookie，Nginx 随机选一台后端，响应中自动注入
Set-Cookie: srv_id=backend-1；后续请求携带该 cookie，Nginx 直接转发至对应机器 - 无需改 Java 代码，不依赖 JSESSIONID 是否存在，也不受 NAT、CDN 或移动网络 IP 变更影响
- 注意：
domain必须带点前缀（如.yourdomain.com）才能跨子域名生效；expires设为合理值（如 1 小时），避免长期绑定导致扩容失衡
若无法编译模块，用 $cookie_jsessionid 做软粘性
适用于已部署的 Java 应用且已正常返回 JSESSIONID Cookie（Tomcat/Spring Boot 默认开启）：
立即学习“Java免费学习笔记（深入）”；
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 在 upstream 中启用一致性哈希：
<!-- 不需第三方模块 -->
upstream backend {
hash $cookie_jsessionid consistent;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
}
- 首次请求没带
JSESSIONID，走轮询；一旦后端生成并返回该 cookie，后续请求就固定路由 - 比
ip_hash更可靠——手机切 WiFi、公司出口 NAT 都不影响 - 缺点：如果后端未正确设置
Path或Domain，浏览器可能不回传 cookie，导致粘性失效；建议 Java 端显式配置：
// Spring Boot 示例
server.servlet.session.cookie.path=/
server.servlet.session.cookie.domain=.yourdomain.com
中大型系统应转向 Redis 统一会话存储
当业务增长、需支持灰度发布、滚动重启或弹性扩缩容时，硬绑定服务器的 sticky 方案会成为瓶颈。此时应让所有后端共享会话状态：
- Java 端接入 spring-session-data-redis（Spring Boot 2.x+ 内置支持）：
# application.yml
spring:
session:
store-type: redis
redis:
host: 192.168.1.20
port: 6379
- Nginx 回归简单轮询或
least_conn，不再承担路由逻辑；所有后端从 Redis 读写 session，任意节点宕机都不丢状态 - 注意：Redis 需开启持久化与高可用（哨兵或 Cluster），避免单点故障导致全站会话清空
- Cookie 本身仍由 Java 应用生成（如 JSESSIONID），但内容已存 Redis，Nginx 不再解析或干预
别踩这些常见坑
- 不要同时开 ip_hash 和 sticky：两者逻辑冲突，Nginx 启动会报错或行为不可控
-
Cookie 的 Domain 设置错误：比如写成
www.yourdomain.com，则api.yourdomain.com下无法读取，导致跨子域会话断裂 -
前端禁用 Cookie 或启用了 Strict SameSite：现代浏览器默认对跨域请求限制 third-party cookie，若 Nginx 与后端域名不同（如 nginx.example.com → app.internal），需确认反向代理路径是否同源，或调整
SameSite=None; Secure -
忽略 HttpOnly 和 Secure 标志：生产环境必须设
HttpOnly=true防 XSS，Secure=true（配合 HTTPS）防明文传输
