高可用架构下解决会话保持的核心是分层组合策略：默认启用cookie粘性提升缓存命中率，同时全量接入redis集中式session存储作为故障兜底，并针对websocket等长连接做协议层协同设计。
粘性路由：快上手但有硬伤
通过负载均衡器（如Nginx、HAProxy、LVS）将同一用户固定到某台后端服务器，常见方式有：
-
基于Cookie的会话粘性：负载均衡器在首次响应中写入
route=server-2类标识，后续请求按该值转发；不改应用代码，部署最快 - 基于源IP哈希：适合四层负载（如LVS），但企业NAT、移动网络IP频繁变动会导致会话中断
优点是低延迟、零改造；缺点也很直接：目标服务器宕机，绑定它的所有用户会话立即丢失，且扩容缩容时会触发批量重绑定。
集中式Session存储：解耦状态与计算
把Session从各节点内存中抽离，统一存到共享存储，所有实例读写同一份数据。Redis是最主流选择，原因包括高性能、支持过期、主从/集群高可用成熟。
- Spring Boot项目只需引入
spring-session-data-redis，配好Redis地址和数据库号即可启用 - Tomcat可通过
RedisSessionManager插件接入；Dify等AI平台也普遍采用此模式 - 关键要避免单点：必须用Redis哨兵（Sentinel）或Cluster集群，而非单节点
这种方式彻底消除单机故障影响，横向扩展无压力，但引入了网络调用开销和Redis自身可用性保障责任。
混合策略：生产环境的务实选择
真实高可用系统很少只用一种方式。更常见的做法是：
- 默认启用Cookie粘性，提升本地缓存命中率，降低Redis访问频次
- 所有服务同时对接Redis Session存储，作为兜底——当某台机器宕机、新请求被切走时，新节点能立刻从Redis重建完整会话上下文
- 配合合理的超时设置（如30分钟），既防长期无效占用，又保障用户操作连续性
这种组合平衡了响应速度、故障恢复能力和运维复杂度，是互联网中大型业务的标准实践。
特别注意WebSocket等长连接场景
HTTP会话保持方案对WebSocket不完全适用。因为连接一旦建立，就长期驻留在某个后端节点上，负载均衡器无法在连接生命周期内重新调度。
- 必须确保WebSocket连接建立前，已通过HTTP握手阶段完成会话初始化并存入Redis
- 后端需支持连接迁移通知或会话广播机制，否则节点宕机会导致长连接直接断开
- 部分架构会引入专门的WebSocket网关，统一管理连接与会话映射关系
这不是简单的“打开sticky session”就能解决的问题，需要协议层与状态层协同设计。
