会话保持本身不导致负载倾斜，但配置不当会使“粘性”固化，造成部分后端长期过载而其他节点闲置；需重点排查sticky是否生效、是否与后端能力匹配、是否掩盖真实瓶颈，如route配置错误、Cookie格式不符、共享存储过载或调度算法冲突。
会话保持本身不导致负载倾斜，但配置不当会让“粘性”变成“固化”，使部分后端长期承载大量会话，而其他节点闲置。排查重点不是去掉 sticky session，而是确认它是否被合理使用、是否与后端能力匹配、是否掩盖了真实瓶颈。
检查 sticky session 是否真在生效
Apache 的 stickysession 不是自动开启的魔法开关，它依赖三个条件同时满足：
- 后端响应中必须包含指定名称的 Cookie（如 JSESSIONID 或 ROUTEID），且值带 route 后缀（如
JSESSIONID=abc123.tomcat1） - Apache 配置中 ProxySet stickysession=xxx 名称必须与 Cookie 名完全一致（大小写敏感）
- 每个 BalancerMember 必须显式声明 route=xxx，且该值要和 Cookie 中的 route 后缀严格对应
若任一条件缺失，stickysession 就退化为普通轮询——此时看似“没粘住”，实则因配置错误导致请求乱跳，反而加剧后端压力波动。用浏览器开发者工具或 curl -I 检查响应头中的 Set-Cookie，确认格式和 route 是否存在。
验证后端节点是否真的“被粘住”且失衡
登录 Apache 的 /balancer-manager 页面（需启用并授权访问），观察各节点的：
- Requests：是否某节点请求数远高于其他（比如 5:1）
- Busy 和 Idle 连接数：是否某节点长期 Busy 占满，而其他大量 Idle
- Status：是否所有节点都显示 OK，排除健康检查误判导致的流量集中
如果发现明显不均，再进一步确认：是用户会话天然集中在少数人（如管理员高频操作），还是所有普通用户都只落到同一台？后者大概率说明 route 配置错误（比如所有后端都用了同一个 route 值）或 Cookie 被前端覆盖（多子域未统一 Domain）。
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
排查会话存储是否成为隐性瓶颈
粘性只是把请求发到固定节点，但如果该节点的会话数据全靠本地文件（session.save_handler = files）或单点 Redis，就可能引发两类倾斜：
- 本地文件存储：高并发下磁盘 I/O 或文件锁争用，让该节点响应变慢，Apache 却因 sticky 继续往里塞请求，形成恶性循环
- 共享 Redis 过载：所有节点共用一个 Redis 实例，而粘住的节点恰好发起大量 session 读写（如频繁 regenerate_id），拖慢整个集群 session 访问
用 redis-cli --latency 或 iostat -x 1 分别检查 Redis 延迟和后端磁盘 await，确认是否存在单点资源打满的情况。
检查调度算法与粘性是否冲突
stickysession 优先级高于负载均衡算法，但算法仍影响新会话的初始分发：
- 若用 byrequests（默认），新用户会按轮询分到各节点——这是合理的
- 若误配成 bybusyness 但又开了 sticky，会导致新会话总被分到当前连接最少的节点，而老会话死守旧节点，长期下来必然失衡
- 更隐蔽的是 max_conns 限制没配：某节点虽粘住大量会话，但 Apache 仍不断往里派新连接，超出其处理能力
建议明确设置 ProxySet lbmethod=byrequests，并在每个 BalancerMember 行加上 max_conns=200（根据后端实际能力调整），防止单节点过载。
