四层会话保持是什么
四层会话保持基于客户端源 IP：同一地址在保持周期内会被固定转发到同一后端。它解决的是「四层看不到 Cookie、又需要会话亲和」的场景，但同时带来一个明显风险——客户端如果经过大型出口 NAT，大量用户可能共享同一个公网 IP，于是被压到同一台后端上。
基本信息
| 原理 | 以客户端源 IP 作为亲和依据 |
|---|---|
| 适用 | TCP/UDP 有状态会话（长连接、登录态） |
| 风险 | 同一出口 IP 的多用户集中到一台后端 |
| 替代方案 | 改用一致性哈希调度或七层 Cookie 保持 |
| 保持时长 | 设置过长会让后端扩容后流量长期不均衡 |
| 适用范围 | 四层监听；七层监听应使用 Cookie 保持 |
典型使用场景
- 非 HTTP 的有状态协议需要把同一客户端固定到同一后端
- 长连接服务在扩缩容后希望存量客户端不频繁漂移
- 自研协议按客户端维度维护会话状态
- 排障期间固定特定客户端流量到指定实例
- 与一致性哈希对比后确认源 IP 粒度更适合业务语义
观察客户端来源分布
观察客户端来源分布
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20
# 通过来源 IP 分布判断是否存在大型出口 NAT 集中访问
ss -tan | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head
# 结合后端实例连接数观察是否出现单机倾斜取舍对照
| 方案 | 亲和粒度 | 主要风险 |
|---|---|---|
| 四层会话保持 | 客户端源 IP | 出口 NAT 场景下单后端过载 |
| 一致性哈希 | 源 IP 或指定键 | 成员变化引发重映射 |
| 七层 Cookie 保持 | 会话/浏览器 | API 客户端不回传 Cookie |
| 不启用粘性 | 无 | 有状态服务需改造为集中式存储 |
企业出口 NAT（许多客户端共享一个公网 IP）场景启用四层会话保持前，先估算单后端能否承载整个出口的流量，必要时改用七层 Cookie 保持。
保持时长与后端扩容要一起考虑：时长设置过长时，新扩容的实例在很长一段时间内分不到流量，扩容效果被打折。