负载均衡需主动设计会话保持策略：一是粘性路由（如基于cookie或ip哈希），二是集中存储（如redis）。前者部署快但容错差，后者高可用但运维复杂；生产常用混合策略，兼顾性能与可靠性。
负载均衡本身不保存用户状态，会话保持不是“自动发生”的事，而是必须主动设计的策略。核心在于两点：要么让请求总回到同一台服务器（粘性路由），要么让所有服务器能读取同一份会话数据（集中存储）。选哪种，取决于业务对一致性、容错性和运维复杂度的要求。
基于Cookie的会话粘性
这是最常用、侵入性最小的方案。负载均衡器（如Nginx、HAProxy）在首次响应中写入一个标识后端服务器的Cookie（例如 route=server-1），后续请求携带该Cookie时，它就按值把请求固定转发到对应实例。
- Nginx配置示例：
upstream backend { server 10.0.0.1; server 10.0.0.2; hash $cookie_route consistent; } - 优点是部署快、无需改应用代码，适合登录态简单、允许单点故障影响部分用户的场景
- 缺点也很明显：某台服务器宕机，绑定它的用户会话立即失效；扩容缩容时，部分用户会被重新分配，导致短暂登出
基于Redis的Session集中存储
把Session数据从各服务器内存里抽出来，统一存到Redis集群中。所有后端实例启动时都配置连接同一个Redis，读写Session都走它。
- Spring Boot项目只需在
application.yml中启用Redis Session支持，并配置host、port、database等参数 - Java应用可引入
spring-session-data-redis，Tomcat可配置RedisSessionManager - 优势在于彻底解耦服务器与状态，任意节点故障不影响用户会话；横向扩展无状态压力
- 需关注Redis高可用（主从+哨兵或Cluster）、连接池配置、序列化兼容性，避免因缓存抖动引发大面积会话丢失
IP哈希与适用边界
四层负载均衡（如LVS、部分云厂商CLB）支持基于源IP做哈希分发，同一IP的请求始终落到同一台后端。
- 配置简单，不依赖Cookie，对移动端或代理环境有一定适应性
- 但真实网络中，多个用户可能共用出口IP（如企业NAT、校园网），导致流量倾斜甚至会话冲突
- 用户IP变动（如移动网络切换基站）会直接中断会话，不适合强连续性要求的业务
- 仅适用于后端规模稳定、用户IP相对固定的内部系统或低敏感度场景
混合策略：粘性+兜底存储
生产环境常组合使用——先用Cookie粘性提升本地缓存命中率，再以Redis为兜底。即使某台服务器临时不可用，负载均衡器可将新请求切到其他节点，而新节点能从Redis快速重建会话上下文。
- 关键点是设置合理的会话超时时间（如30分钟无操作自动过期），避免脏数据堆积
- 敏感操作（如支付、密码修改）建议强制二次校验，不完全信任Session中的身份标识
- 监控Redis延迟、命中率、连接数，以及各后端节点的Session读写日志，能提前发现共享瓶颈
