Nginx Sticky Session：让会话在负载均衡中“锚定”

当你在购物APP里把商品加入购物车，切换WiFi后却发现商品消失；或是在支付过程中突然跳转回登录页面——这些看似“bug”的体验问题，往往源于会话管理的漏洞。在分布式服务架构中，如何让用户的操作始终“记得”自己的状态？Nginx的Sticky Session技术，正是解决这一问题的关键。

会话一致性：高并发下的“隐形需求”

在传统单体应用中，会话数据通常由单一服务器存储。但当业务扩展到多服务器集群时，负载均衡器会将请求随机或轮询分配给不同后端。若没有会话保持机制，用户首次请求可能落在服务器A，后续请求却被分配到服务器B，而B服务器可能没有该用户的会话数据，导致“购物车清空”“登录失效”等问题。

Sticky Session的核心目标是通过规则绑定，让同一用户的请求始终流向特定后端服务器，确保会话数据在集群间共享。Nginx作为反向代理与负载均衡的“瑞士军刀”，提供了两种主流实现方式：基于IP哈希和基于Cookie插入。

两种实现方式：从简单到灵活

1. IP哈希：最简单的会话绑定

通过ip_hash指令，Nginx根据客户端IP地址的哈希值固定分配后端服务器。例如：

upstream backend_servers {
    server backend1.example.com;
    server backend2.example.com;
    ip_hash;  # 固定IP到服务器的映射
}

这种方式无需额外配置，适合IP固定的场景（如企业内网用户）。但缺点也很明显：若用户通过NAT网关切换网络，IP变化会导致会话失效；若多个用户共享同一IP（如家庭WiFi），可能出现“多人会话冲突”。

2. Cookie插入：更灵活的会话标识

相比IP哈希，基于Cookie的Sticky Session更适配多终端用户。Nginx通过ngx_http_upstream_cookie_module模块，在首次响应时为用户生成唯一会话标识（如srv_id），并通过Set-Cookie头返回给浏览器。后续请求时，Nginx根据Cookie值识别用户，始终转发到对应服务器：

upstream backend_servers {
    server backend1.example.com;
    server backend2.example.com;
    sticky cookie srv_id expires=1h domain=.example.com path=/;
}

这里expires=1h表示Cookie有效期1小时，domain限制域名，path限定路径。这种方式避免了IP依赖，适合多设备用户（如手机、PC同时访问），但需注意：浏览器禁用Cookie或清除缓存会导致会话失效，且Cookie大小受浏览器限制（通常≤4KB）。

场景适配：选对方案事半功倍

• 电商购物车、支付流程：需强会话一致性，建议用Cookie-based方式，避免用户中途刷新导致状态丢失。
• 企业内部管理系统：IP地址相对固定，可优先选择IP哈希，简化配置。
• 混合网络环境：如同时支持内网VPN和公网动态IP，可结合两种方式，优先Cookie识别，IP冲突时降级使用哈希。

总结：平衡性能与体验的关键

Sticky Session的本质是在分布式系统中构建“会话锚点”。Nginx的两种实现方式各有优劣：IP哈希简单可靠但依赖IP，Cookie-based灵活适配多场景但需处理浏览器兼容性。在高并发场景下，合理选择并配置Sticky Session，既能保障用户体验的连贯性，又能避免后端服务器负载失衡，是微服务架构中不可忽视的技术细节。