推荐方案是基于redis的集中式session存储，即将session统一存入redis集群，所有服务器通过redis客户端读写会话，实现高性能、高可用、自动过期的共享session。
Web 应用部署到多台服务器组成集群后，用户请求可能被负载均衡分发到任意节点。而默认情况下，Session 只存在单台服务器内存中，一旦请求落到其他机器，就找不到对应会话——用户会突然掉登录、购物车清空、表单提交失败。解决这个问题的核心思路是：让所有服务器能访问同一份会话数据，或确保请求始终落在同一台服务器上。
基于 Redis 的集中式 Session 存储
这是目前最主流、推荐度最高的方案。把 Session 数据统一存入 Redis（或其他高性能内存存储），各应用服务器不再本地保存，而是通过 Redis 客户端读写会话。
- 优点：性能高、扩展性好、天然支持故障转移；Redis 支持自动过期，与 Session 生命周期天然契合
- 适用场景：中大型业务、需要水平扩容、对可用性要求高的系统
- 典型实现：Spring Boot 项目引入
spring-session-data-redis，配置 Redis 连接参数，无需修改业务代码；Tomcat 可通过tomcat-redis-session-manager插件接入 - 注意点：Session 对象需可序列化；敏感字段（如 token）建议加密后再存；避免在 Session 中存大量数据，防止 Redis 内存压力过大
粘性会话（Sticky Session / Session Binding）
由负载均衡器（如 Nginx、HAProxy）根据客户端特征（如 IP 或 Cookie 中的 session ID）做哈希路由，确保同一用户后续请求始终打到同一台后端服务器。
- 优点：零改造成本，不依赖外部组件，适合快速上线或小规模集群
- 缺点：单点失效风险——某台服务器宕机，其上的 Session 全部丢失；无法真正实现无状态伸缩；IP 变更（如移动网络切换）会导致会话中断
- 常用配置：Nginx 中启用
ip_hash或hash $cookie_JSESSIONID;；AWS ALB 支持基于 Cookie 的亲和性（Sticky Sessions）
Session 复制（Replication）
应用服务器之间实时同步 Session 数据，每台节点都持有一份全量副本。常见于老版本 Tomcat 集群（通过 <distributable></distributable> 和 Cluster 配置启用）。
- 优点：不依赖第三方服务，故障时仍可本地读取
- 缺点：网络开销大，节点越多广播越重；内存占用翻倍；存在复制延迟，极端情况下出现脏读；已逐步被业界弃用
- 适用场景：极小规模（≤3 节点）、短期过渡、无法引入中间件的受限环境
无状态 Token 方案（如 JWT）
彻底放弃服务端 Session，改由客户端携带加密签名的 Token（如 JWT）。Token 中包含必要用户标识和权限信息，服务端每次只需校验签名和有效期，无需查存储。
- 优点：完全无状态、天然适合微服务与跨域；减轻服务端存储与网络压力
- 缺点：Token 无法主动失效（需配合黑名单或短生命周期）；敏感信息不宜明文存入；Payload 有大小限制（一般 ≤4KB）
- 适用场景：API 优先架构、前后端分离、移动端 App、对伸缩性要求极高的系统
- 补充：可结合 Redis 缓存 Token 黑名单，兼顾灵活性与安全性
