apache mod_proxy_balancer实现会话粘滞有两种主流方式：基于cookie的stickysession（依赖后端输出.route后缀的会话id，如jsessionid=abc123.node1）和基于源ip的iphash（需启用mod_lbmethod_iphash.so并配置lbmethod=iphash，直接对真实客户端ip哈希分发）。
Apache mod_proxy_balancer 实现会话粘滞，核心是让同一用户后续请求始终打到同一台后端服务器。它不靠应用层 Session 共享，而是通过两种主流方式：基于 Cookie 的 sticky session（依赖后端输出路由标识），或基于客户端真实 IP 的一致性哈希（无需后端配合）。选哪种取决于你的架构约束——比如后端是否已支持 session 共享、前端是否有 CDN、用户 IP 是否稳定。
基于 Cookie 的 stickysession（推荐用于 Java/Tomcat 等有标准会话机制的场景）
这是最常用、兼容性最好的方式，Apache 从响应 Cookie 中提取 .route 后缀，匹配后端节点的 route 值，实现绑定。
- 确保启用三个模块：
mod_proxy.so、mod_proxy_balancer.so、mod_proxy_http.so（或mod_proxy_ajp.so） - 每个后端节点必须声明
route，且值要与后端实际配置一致（如 Tomcat 的jvmRoute="node1"） -
ProxyPass指令中显式写入stickysession=JSESSIONID|jsessionid，大小写变体用竖线分隔，避免因首字母大小写导致匹配失败 - 加
nofailover=Off：当原节点宕机时允许切走，避免用户直接报错；设为On则强制不切换，但可能造成服务中断 - 后端必须在 Set-Cookie 响应头中带
.node1这样的后缀，例如JSESSIONID=abc123.node1
基于源 IP 的 iphash（适合无状态服务或 session 尚未共享的过渡期）
不依赖 Cookie、不依赖后端输出，直接对客户端真实 IP 做哈希，天然保证同一 IP 总落到同一节点。但前提是 Apache 能拿到真实 IP。
Ai Coach Batch Session Summary
下载
批量分析录音转写，输出多维度拓客报告。触发词：录音分析、总结、音频总结、拜访记录总结。当用户提及「分析录音」「看看录音数据」「最近的录音」「通话记录」且意图为批量统计/分析时触发。仅出现「录音」或「拜访」时需结合上下文，若仅查看单条详情则不触发。
- 必须额外启用调度模块：
mod_lbmethod_iphash.so（2.4+ 版本）或mod_lbmethod_byrequests.so（部分文档误写，实际 iphash 功能由前者提供） -
<proxy></proxy>块内用ProxySet lbmethod=iphash显式启用，不能只写在 ProxyPass 行里 - 若前端有 Nginx、CDN 或其他反向代理，需配置
RemoteIPHeader X-Forwarded-For和RemoteIPInternalProxy，否则哈希基于代理 IP，失去意义 - 无需
stickysession、无需route、无需后端改任何代码——只要后端无状态或 session 已共享，就能稳定运行
常见陷阱与验证要点
配置写完不等于生效，容易忽略的细节决定成败：
- 模块加载顺序无关紧要，但缺任何一个必要模块（尤其是
lbmethod_iphash或proxy_http），Apache 启动会报错或静默回退到轮询 - 浏览器开发者工具看响应头：确认 Set-Cookie 是否含
.node1（Cookie 方式），或用 curl -v 查看不同 IP 请求是否命中相同后端（IP 方式） - 多集群共用域名时，stickysession 的 Cookie 名必须唯一，比如用
CLUSTER_A_JSESSIONID避免冲突 - 动态增删节点（通过 balancer-manager）会导致已有粘性会话失效，除非应用本身无状态或使用 force 参数
怎么选：Cookie 还是 IP？
如果后端已部署 Tomcat 并配好 jvmRoute，优先用 Cookie 方式——它更精准，不受 NAT 或移动网络 IP 变动影响；如果后端是 Go/Python 无状态服务，或你正处在 session 共享改造中途，IP 哈希更轻量、更易落地。两者不互斥，可按业务路径分流使用。
