常用部署环境 Sticky Session 配置操作文档

一、概述

Sticky Session（会话保持） 是一种负载均衡策略，确保同一客户端的请求始终路由到固定的后端服务器。适用于需要本地化 Session 存储的场景（如游戏、购物车、临时会话等）。本文档涵盖主流平台的配置方法及注意事项。

二、配置方法

1. Nginx 配置

适用场景 ：传统 Web 服务器负载均衡。
步骤：

在 http 或 upstream 块中定义负载均衡组，并启用 ip_hash ：

nginx 复制代码

upstream backend {
    ip_hash;  # 基于客户端 IP 哈希分配
    server 10.0.0.1:8080;
    server 10.0.0.2:8080;
}

若需更灵活的哈希键（如 Cookie），使用 hash指令：

nginx 复制代码

upstream backend {
    hash $cookie_jsessionid;  # 基于特定 Cookie 值
    server 10.0.0.1:8080;
    server 10.0.0.2:8080;
}

验证方法：

多次刷新页面，检查 upstream_addr 是否固定。
注意事项：
ip_hash 依赖客户端 IP，代理环境需使用 $proxy_add_x_forwarded_for。
后端节点扩容/缩容时，部分会话会重新分配。

2. HAProxy 配置

适用场景 ：TCP/HTTP 层负载均衡。
步骤：

使用 cookie参数配置粘性会话：

haproxy 复制代码

backend app_servers
    balance uri
    cookie SRV insert indirect nocache
    server s1 10.0.0.1:8080 check cookie s1
    server s2 10.0.0.2:8080 check cookie s2

若基于 HTTP Header：

haproxy 复制代码

backend app_servers
    balance uri
    hash-type consistent
    hdr_sub(X-User-ID) set
    server s1 10.0.0.1:8080 check
    server s2 10.0.0.2:8080 check

验证方法：

检查客户端请求中是否携带 Set-Cookie: SRV=...。
注意事项：
insert 模式会自动注入 Cookie，需确保客户端支持。

3. AWS ALB（Application Load Balancer）

适用场景 ：AWS 云环境。
步骤：

启用

粘性会话（基于应用 Cookie）：
- 控制台路径：ALB → Listeners → Edit → Advanced → Sticky Sessions → Enabled。
- 配置 Cookie 名称（如 myapp-cookie），并设置过期时间。
应用需返回对应 Cookie：
http 复制代码
```
Set-Cookie: myapp-cookie=abc123; Path=/
```

验证方法：

使用 curl -I 检查响应头中的 Cookie，并重复请求验证一致性。
注意事项：
Cookie 由负载均衡器注入，需与后端服务 Session 机制兼容。

4. 阿里云 ASM（服务网格）

适用场景 ：Kubernetes + Istio 服务网格。
步骤：

创建 DestinationRule配置一致性哈希：

yaml 复制代码

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: sticky-session
spec:
  host: your-service
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpCookie:
          name: sticky-session-key
          ttl: 0s  # 0s 表示由网关生成

部署后，网关会自动注入 Cookie 并路由请求。
验证方法：

使用浏览器开发者工具检查请求中的 Cookie，并查看日志中的 upstream_addr。
注意事项：
默认使用 RingHash 算法，支持 Maglev（需 ASM 1.16+）。

5. Kubernetes Ingress（Nginx Ingress Controller）

适用场景 ：K8s 集群部署。
步骤：

通过注解启用 Sticky Session：

yaml 复制代码

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: your-ingress
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "50"

（需配合canary模式实现简单粘性会话）

推荐方案 ：结合 Redis 共享 Session，避免依赖粘性会话。
注意事项：

标准 Nginx Ingress 不直接支持 Sticky Session，需通过扩展或自定义配置实现。

6. Cloud Foundry

适用场景 ：PaaS 平台部署。
步骤：

应用需返回 JSESSIONIDCookie：

http 复制代码

Set-Cookie: JSESSIONID=1A530637289A03B07199A44E8D531427; Path=/

CF 路由层自动生成 VCAP_ID标识实例：
http 复制代码
```
X-CF-Instance-ID: 323f211e-fea3-4161-9bd1-615392327913
```

验证方法：

检查请求头中的 X-CF-Instance-ID 是否一致。
注意事项：
实例故障时需依赖 VCAP_ID 重定向至新实例，需应用层兼容。

三、替代方案（推荐优先使用）

集中式 Session 存储：
- 使用 Redis/Memcached 共享 Session，后端无状态化。
Token 认证：
- JWT 等无状态认证机制，避免依赖服务器本地 Session。

四、常见问题排查

会话丢失：
- 检查后端节点健康状态，确认负载均衡策略是否生效。
Cookie 未注入：
- 验证应用是否返回指定 Cookie，网关配置是否正确。
扩容异常：
- 使用一致性哈希算法（如 Maglev）减少节点变动影响。

五、附录

Sticky Session 优缺点对比：

优点缺点

配置简单容错性差

无需共享存储扩容缩容时会话中断
推荐阅读：
- 《分布式 Session 设计》
- Istio 官方文档：Consistent Hash Load Balancing

优点	缺点
配置简单	容错性差
无需共享存储	扩容缩容时会话中断