负载均衡接入后session会话保持需主动配置，核心方案只有两种：一是请求固定路由至同一服务器（如ip_hash或cookie粘性），二是所有服务器共享session仓库（如redis集中存储）；前者实施快但容错差，后者高可用但依赖缓存稳定性。

负载均衡接入后，Session会话保持不是自动生效的，必须根据业务特点主动配置策略。核心思路只有两个：要么让请求“认准一台服务器不换”，要么让所有服务器“共用一个Session仓库”。选哪种，取决于你对故障容忍度、运维能力、安全要求和用户连续性的综合判断。

基于客户端IP的哈希分发（简单快，适合内网或低敏感场景）

这是Nginx、LVS等四层/七层负载均衡器最易上手的方式。配置一行 ip_hash 即可，负载均衡器会对用户源IP做哈希运算，固定映射到某台后端节点。

• 优点：零代码改造、无需改应用、部署极快
• 缺点明显：企业NAT、校园网、移动网络下多个用户共用IP，会导致流量倾斜甚至会话串扰；用户IP一变（比如4G切WiFi），会话立即中断；后端节点宕机时，绑定该节点的所有用户登录态丢失
• 适用场景：内部管理系统、测试环境、用户IP稳定且规模小的B端服务

基于Cookie的粘性路由（平衡体验与实施成本）

比IP哈希更精准，主流负载均衡器（Nginx sticky模块、HAProxy的cookie insert、云厂商CLB）都支持。首次请求时，负载均衡器生成唯一标识（如 ROUTEID=server-2）写入响应Cookie；后续请求携带该Cookie，就被定向转发到对应服务器。

Ai Coach Batch Session Summary

批量分析录音转写，输出多维度拓客报告。触发词：录音分析、总结、音频总结、拜访记录总结。当用户提及「分析录音」「看看录音数据」「最近的录音」「通话记录」且意图为批量统计/分析时触发。仅出现「录音」或「拜访」时需结合上下文，若仅查看单条详情则不触发。

下载

• 不依赖用户IP，对移动端和代理友好
• 应用无需修改，Session仍存本地内存，性能损耗小
• 风险仍在：目标服务器宕机，这部分用户会话失效；扩容缩容时部分用户被重分配，可能短暂登出

Session集中存储（生产环境推荐方案）

把Session数据从各服务器内存中抽离，统一存到Redis集群。所有后端实例启动时连接同一套Redis，读写Session全部走它。Spring Boot加几行配置、Tomcat配个RedisSessionManager就能启用。

• 彻底解耦服务器与状态：任意节点故障、上下线、扩缩容，用户无感知
• 需同步关注Redis高可用（主从+哨兵或Cluster）、连接池参数、序列化兼容性，否则缓存抖动会引发大面积会话丢失
• 额外开销是网络延迟和Redis稳定性依赖，但换来的是真正的高可用

混合策略：粘性+兜底存储（兼顾性能与韧性）

真实生产常用组合——前端用Cookie做粘性，提升本地缓存命中率；后端所有节点同时对接Redis作为Session兜底。这样即使某台服务器临时不可用，新请求被调度到其他节点时，能立刻从Redis重建完整会话上下文。

• 关键细节：设置合理超时（如30分钟无操作自动过期），避免脏数据堆积
• 需要确保Cookie和Redis中的Session生命周期协同，例如登录成功后双写、登出时双删