七层会话保持怎么实现
七层会话保持通过 Cookie 实现：负载均衡要么在响应中植入一个标识后端的 Cookie，要么重写后端自己下发的 Cookie，后续携带该 Cookie 的请求会被持续转发到同一后端。它适合登录态、购物车等有状态 Web 服务，但前提是客户端会保存并回传 Cookie，纯 API 调用方通常不满足这个条件。
基本信息
| 实现方式 | 植入 Cookie（负载均衡生成）或重写 Cookie（后端定义） |
|---|---|
| 生效范围 | 仅 HTTP/HTTPS 监听 |
| 超时 | 保持时长由产品参数控制，需要与后端会话超时对齐 |
| 前提 | 客户端要保存并回传 Cookie；纯 API 客户端需自行处理 |
| 与调度算法关系 | 会话保持叠加在调度算法之上，只对命中保持的请求生效 |
| 适用场景 | 有状态 Web 服务；无状态服务通常不需要开启 |
典型使用场景
- 传统 Web 应用把会话存在本地内存，需要把同一用户固定到同一后端
- 购物车等状态数据未做集中存储，依赖实例本地保存
- 灰度期间让同一用户持续访问同一版本，避免体验来回切换
- 排障时固定某用户到特定实例，便于结合日志定位问题
- 与一致性哈希配合前先评估，避免两种粘性机制叠加
检查响应中的 Cookie 与转发头
检查响应中的 Cookie 与转发头
curl -sv -H 'Host: shop.example.com' http://<LB地址>/ 2>&1 \
| grep -i -E 'set-cookie|x-forwarded'
# 观察响应是否植入了会话保持 Cookie
# 再次携带该 Cookie 发起请求，观察是否始终落到同一后端（对比返回内容）配置要点
| 项目 | 说明 | 注意 |
|---|---|---|
| Cookie 来源 | 负载均衡植入或后端定义 | 重写模式下后端 Cookie 名需与配置一致 |
| 保持超时 | 会话粘性的有效时长 | 短于后端会话超时会导致会话丢失 |
| 适用协议 | HTTP / HTTPS | 四层监听不解析 Cookie |
| 客户端要求 | 能保存并回传 Cookie | API 客户端通常不符合 |
不存储 Cookie 的 API 客户端上，Cookie 会话保持相当于未启用，这类流量仍由调度算法分配；如果确实需要粘性，应改用一致性哈希。
保持超时与后端会话超时要一起看：负载均衡的粘性先到期时，请求会被分配到别的后端，用户侧表现为「登录状态莫名丢失」。