负载均衡会话保持是什么
会话保持（sticky）让同一客户端在一定时间内的请求持续落到同一台后端服务器上。需要它的原因是无状态之外的业务：登录态存在单机内存、上传与下载分阶段进行、下单与支付跨多个请求。实现方式主要有源地址哈希、Cookie 插入或改写、以及设备侧会话表保持。保持粒度越粗，负载越不均匀，这是设计时必须权衡的取舍。
基本信息
| 实现方式 | 源地址哈希、Cookie 插入或改写、会话表保持 |
|---|---|
| 适用业务 | 带登录态的应用、分阶段上传下载、跨请求事务 |
| 代价 | 保持粒度越粗负载越不均匀 |
| 保持时长 | 按会话有效期设置，过长会影响后端扩容后的流量分摊 |
| 失效场景 | 出口 NAT 后大量用户共用同一源地址 |
典型使用场景
- 老系统会话存单机内存：不保持会导致用户频繁掉线
- 文件上传与处理分两个接口，需要落到同一台后端
- 购物车与下单流程跨多个请求，需保持在同一实例
- WebSocket 长连接：连接建立后必须保持
- 后端扩容或缩容时，评估保持策略对流量重分布的影响
- 公网用户经多层 NAT 接入，源地址哈希失衡需要改用应用层标识
选择建议
选择建议
# HTTP 业务：优先使用会话 Cookie（跨源 NAT 稳定）
# 非 HTTP 业务：源地址哈希 + 较短的保持时间
# 长连接业务：按连接保持，连接断开后重新分配
# 多出口上网用户：源地址会变化，不适合源地址哈希
# 后端有多个可用组时：保持只在同一组内生效，需确认组设计保持方式对比
| 方式 | 优点 | 局限 |
|---|---|---|
| 源地址哈希 | 无需改动应用，配置简单 | NAT 后大量用户同源，负载严重失衡 |
| Cookie 保持 | 按会话精确保持，跨源稳定 | 需应用允许插入或改写 Cookie |
| 会话表保持 | 对应用透明 | 表项容量有限，超时后重新分配 |
| 按连接保持 | 适合长连接协议 | 短连接业务效果有限 |
公网用户经多层 NAT 后源地址可能大量相同，此时源地址哈希会让流量集中到少数后端，形同没有负载均衡。
保持时间过长会拖慢后端扩容后的流量分摊：新加入的后端长时间收不到已有用户的请求，扩容效果延迟显现。