播面

在集群（多服务器）环境下，传统的将 Session 保存在单机内存中的方式会失效，因为用户的请求可能会被负载均衡器分发到不同的服务器上，导致用户在一个服务器登录后，下一次请求到了另一台服务器却显示未登录。

解决 Session 共享问题主要有以下 4 种主流方案，按推荐程度由低到高排列：

---

1. Session 复制 (Session Replication)

这是 Web 容器（如 Tomcat, JBoss）自带的功能。

• 原理：多台服务器之间通过网络组播（Multicast）同步 Session 数据。当一台服务器产生 Session，它会把数据复制到集群内的其他所有服务器。
• 优点：
  • 无需修改代码，只需修改容器配置（如 Tomcat 的 server.xml）。
  • 如果一台服务器宕机，其他服务器上有备份，用户无感知。
• 缺点：
  • 性能差：同步数据需要消耗大量网络带宽。
  • 扩展性差：随着节点增加，同步负担呈指数级上升，通常集群超过 4-5 台机器后性能会急剧下降。
  • 内存浪费：每台服务器都保存所有用户的 Session，内存利用率低。
• 适用场景：小型集群（2-3 台机器），且不想引入外部依赖。

2. Session 黏滞 (Session Sticky / IP Hash)

这是在负载均衡层（如 Nginx, F5, HAProxy）解决问题。

• 原理：负载均衡器根据请求来源的 IP 地址进行 Hash 计算，保证同一个 IP 的请求永远只分发到同一台服务器上。
• 优点：
  • 配置简单（如 Nginx 只需要配置 ip_hash）。
  • 应用服务器不需要做任何修改，完全透明。
• 缺点：
  • 单点故障：如果某台服务器宕机，该服务器上的所有 Session 全部丢失，用户会被强制登出。
  • 负载不均：如果大量用户来自同一个局域网（公网 IP 相同），流量会全部打到同一台服务器，导致负载倾斜。
• 适用场景：对高可用要求不严苛的内部系统或小型系统。

3. Session 集中存储 (Session Separation) —— 最推荐方案

这是目前企业级开发中最常用的方案，通常配合 Redis 使用。

• 原理：将 Session 从 Web 服务器的内存中剥离出来，统一存储到一个独立的、高性能的存储介质中（如 Redis、Memcached 或 数据库）。所有服务器处理请求时，都去这个中心存储拿 Session。
• 实现方式：
  • Spring Session：Java 生态中的标准解决方案。它重写了 HttpServletRequest，拦截 Session 操作并自动代理到 Redis 中。
• 优点：
  • 高可用：服务器重启或扩容，Session 不会丢失（只要 Redis 还在）。
  • 水平扩展：应用服务器可以无限横向扩展，无状态化。
  • 跨应用共享：不同的服务（如单点登录 SSO）可以共享 Session 数据。
• 缺点：
  • 引入了新的依赖（Redis），增加了系统复杂度。
  • 每次请求都需要网络通信读取 Session，有极其微小的延迟（通常可忽略）。
• 适用场景：中大型分布式系统、微服务架构。

4. 基于 Token 的无状态认证 (JWT)

这本质上是放弃 Session，改用 Token 机制。

• 原理：服务端不存储 Session。用户登录后，服务端生成一个包含用户信息的加密字符串（Token，如 JWT），发给客户端。客户端将其存储（Cookie 或 LocalStorage），每次请求都带上这个 Token。服务端只需验证 Token 的签名即可确认用户身份。
• 优点：
  • 服务端彻底无状态：极易扩展。
  • 性能好：不需要查库或查 Redis，直接 CPU 计算验签。
  • 跨域友好：适合前后端分离和移动端 APP。
• 缺点：
  • 注销困难：Token 一旦签发，在有效期内一直有效。要实现“强制踢人”或“注销”，需要引入黑名单机制（又变回了类似 Session 的存储）。
  • 带宽占用：Token 包含用户信息，通常比 SessionID 长很多。
• 适用场景：API 接口服务、微服务内部调用、移动端后端。

---

总结与选型建议

结论：
如果是传统的 Web 项目改造，首选 Spring Session + Redis 方案；如果是全新的前后端分离或微服务架构，优先考虑 JWT (Token) 方案。