Redis集中存储+Ngins基础负载均衡是当前最成熟可落地的Session共享方案，通过将Session从应用内存剥离并统一写入高可用Redis集群，实现多节点间会话一致性与无状态扩展。
在 Nginx 高可用架构中，Session 会话共享不是“选配”，而是保障用户状态连续性的刚性需求。单纯依赖 Nginx 转发逻辑无法解决后端多实例间的会话隔离问题，必须结合存储层与路由策略协同设计。当前生产环境最成熟、可落地的方案是Redis 集中存储 + Nginx 基础负载均衡，兼顾一致性、性能与运维可控性。
优先采用 Redis 存储 Session（推荐主从+哨兵）
将 Session 数据从 Tomcat 或 Spring Boot 应用内存中剥离，统一写入 Redis，所有后端节点通过同一 Redis 实例（或高可用集群）读写会话。
- Tomcat 场景：集成
tomcat-redis-session-manager，配置context.xml指向 Redis Sentinel 地址，自动处理故障转移 - Spring Boot 场景：引入
spring-session-data-redis，配合@EnableRedisHttpSession，原生支持序列化与过期管理 - 关键配置项：设置合理的
maxInactiveIntervalInSeconds（如 1800 秒），避免 Redis 内存积压；启用saveMode=ON_SET_OR_GET减少无效写入
慎用粘性会话（Sticky Session），仅作兜底或过渡
ip_hash 或 cookie-based sticky 在小规模、低变更场景下见效快，但存在明显短板，不建议作为长期主方案。
- ip_hash 易受 NAT、移动网络 IP 漂移影响，导致会话中断；增减后端节点时 hash 重分布，大量用户 session 失效
- cookie 粘性（如 nginx-sticky-module）需编译安装，且 srv_id 无法感知后端健康状态——节点宕机后流量仍被错误路由
- 若必须使用，建议仅用于灰度发布或数据库迁移期间的临时会话保持，同时开启 Redis 同步双写，确保平滑切换
避免使用数据库或文件存储 Session
MySQL 或本地文件系统承载 Session 属于反模式，已基本被淘汰。
- 数据库 IO 成为瓶颈：每次请求都要查 session 表，QPS 上千即显压力，且事务锁和连接池易耗尽
- 文件同步不可靠：NFS 共享目录存在缓存一致性风险，多节点写入冲突概率高，无自动过期机制
- 即使使用 MySQL，也应仅限于审计日志或冷备导出，而非实时会话读写路径
安全与可观测性必须同步落地
Session 共享引入新组件，也带来新攻击面和排查盲区，需配套加固与监控。
- Redis 连接必须启用密码认证与 TLS 加密，禁用
CONFIG命令，限制客户端 IP 白名单 - 在 Nginx 日志中添加
$cookie_JSESSIONID或$cookie_SPRING_SESSION字段，便于追踪会话流转 - 部署 Prometheus + Redis Exporter 监控 key 数量、命中率、平均 TTL；应用层埋点统计 session 创建/销毁速率，及时发现泄漏
