本质是架构设计与状态管理不匹配，应采用Redis等集中式存储解耦Session，使应用节点成为无状态计算单元，天然支持横向扩展与故障恢复，避免Sticky Session和Session复制的固有缺陷。
负载均衡下会话失效，本质不是技术故障，而是架构设计与状态管理不匹配的结果。用户登录后刷新页面突然登出、购物车清空、表单提交报未授权——这些现象背后，是 Session 未在多节点间正确共享。真正可靠的方案，不是让请求“总回到同一台机器”，而是让 Session 数据本身具备全局可读写能力。
优先用集中式存储解耦 Session
把 Session 从应用服务器内存里移出来，存到 Redis 或 Memcached 这类独立缓存服务中，是最主流也最稳健的做法。应用节点变成纯计算单元，每次请求都去 Redis 读写 Session，天然支持横向扩容、节点故障自动恢复。
- Redis 推荐启用集群模式（如 Redis Cluster）或哨兵模式，避免单点风险；TTL 设置需略长于业务最大闲置时长（如 30 分钟），防止误删活跃会话
- Spring Boot 项目可直接配置
spring.session.store-type=redis，配合spring.redis连接参数即可生效 - 注意序列化方式：默认 Java 序列化存在兼容性与安全风险，建议改用 JSON 或 Kryo，并确保所有存入 Session 的对象可序列化
慎用会话保持（Sticky Session）
像 Nginx 的 ip_hash 或插入 Cookie 的粘性路由，能快速缓解问题，但只是临时补丁，不是高可用方案。
- IP 地址可能被 NAT 共享（如企业出口、移动网络），导致多个用户被绑定到同一节点，引发负载倾斜
- 某台服务器宕机时，其上所有会话立即丢失，用户需重新登录，违背高可用目标
- 新增节点后，旧用户仍被固定路由，无法享受新资源，扩容形同虚设
避免数据库直存 Session
虽然 MySQL 或 PostgreSQL 能持久化 Session，但不推荐作为主方案。
- 每次 HTTP 请求都要查一次数据库，IO 成为瓶颈，QPS 上不去，尤其在秒杀、抢购等高峰场景
- Session 是高频读写、短生命周期数据，关系型数据库的事务开销和连接池压力明显高于缓存
- 若必须用 DB，建议仅作兜底（如 Redis 故障时降级），并单独建库/表，避免污染核心业务库
不建议在生产环境用 Session 复制
Tomcat 的 DeltaManager 或 Hazelcast 等复制机制，只适合节点数 ≤3～5 的小规模集群。
- 节点数每增加 1，广播同步消息量呈平方增长，10 节点时网络带宽和 CPU 消耗陡升
- 跨机房部署时，毫秒级延迟会导致复制超时甚至丢包，会话状态不一致概率显著上升
- 任一节点 GC 卡顿或网络抖动，都可能阻塞全集群的 Session 写入，影响整体可用性
