会话保持与共享存储

负载均衡环境下同一用户的请求可能被分发到不同后端。对于有状态应用（如购物车、登录会话），需要会话保持确保路由一致性。

基于 IP 的会话保持

ip_hash

upstream backend {
    ip_hash;
    
    server 10.0.0.1:8080;
    server 10.0.0.2:8080;
}

根据客户端 IP 的 hash 值分配后端。同一 IP 始终路由到同一服务器。缺点是 NAT 用户群会被分配到同一后端，导致负载不均。

hash 自定义

upstream backend {
    hash $cookie_session_id consistent;
    
    server 10.0.0.1:8080;
    server 10.0.0.2:8080;
}

按 Cookie 中的 session ID 做 hash。consistent 使用一致性 hash，后端增减时仅最小化重分配。

基于 Cookie 的会话保持

Cookie 注入

upstream backend {
    server 10.0.0.1:8080;
    server 10.0.0.2:8080;
}

server {
    location / {
        proxy_pass http://backend;
        
        # 后端响应中设置 route Cookie
        proxy_cookie_path / "/; httponly; secure";
    }
}

sticky 模块（NGINX Plus）

upstream backend {
    zone backend 64k;
    
    server 10.0.0.1:8080;
    server 10.0.0.2:8080;
    
    sticky cookie srv_id expires=1h domain=.example.com path=/;
}

NGINX Plus 的 sticky 指令自动注入路由 Cookie。开源版需使用 ip_hash 或 hash 替代。

共享存储方案

Redis 共享 Session

# NGINX 仅做负载均衡，会话由后端 Redis 共享
upstream backend {
    least_conn;
    
    server 10.0.0.1:8080;
    server 10.0.0.2:8080;
}

推荐方案：后端使用 Redis/Memcached 共享 Session，NGINX 无需做会话保持。任何后端都能处理任何请求。

NFS 共享存储

# 后端共享 /data 目录
upstream backend {
    server 10.0.0.1:8080;
    server 10.0.0.2:8080;
}

文件级共享（NFS/GlusterFS）适合共享用户上传文件。Session 不推荐放文件系统，性能差且容易不一致。

方案对比

要点总结

• ip_hash 简单但有 NAT 负载不均问题
• hash consistent 按自定义变量做一致性 hash
• 推荐后端使用 Redis/Memcached 共享 Session
• NGINX Plus 支持 sticky 指令注入路由 Cookie
• 共享存储（NFS）适合文件不适合 Session
• 会话保持降低负载均衡效率，共享存储方案最优