负载均衡会话失效：如何处理高可用下 session 同步

本质是架构设计与状态管理不匹配，应采用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 写入，影响整体可用性