Nginx upstream的ip_hash与sticky cookie在会话保持上的差异

Nginx upstream的ip_hash与sticky cookie在会话保持上的差异

在Web应用中，当请求被负载均衡器（如Nginx）分发到后端多个服务器时，保持用户与特定服务器的“粘性”关系至关重要。这种技术被称为会话保持。Nginx的upstream模块提供了两种主流的会话保持配置：ip_hash与sticky cookie。它们的实现原理和适用场景截然不同。

1. ip_hash：基于客户端IP的简单哈希

ip_hash的原理是对客户端的IPv4或IPv6地址进行哈希计算，并将计算结果映射到固定的后端服务器上。只要客户端IP不变，其请求就始终被转发到同一台服务器。

配置方法
在upstream配置块中添加ip_hash指令即可。

upstream backend {
    ip_hash;
    server 192.168.1.101:8080;
    server 192.168.1.102:8080;
    server 192.168.1.103:8080;
}

执行过程

1. Nginx接收到客户端请求（例如，来自 203.0.113.5）。
2. 计算 该IP地址的哈希值。
3. 将 哈希值与配置的服务器列表进行取模运算，确定目标服务器。
4. 转发 该请求至目标服务器（例如 192.168.1.102）。
5. 后续来自同一 203.0.113.5 的请求，哈希结果固定，因此始终被转发到 192.168.1.102。

2. sticky cookie：基于服务器植入的Cookie

sticky cookie（在Nginx商业版或OpenResty等发行版中通常通过sticky指令实现）的原理是：当客户端首次请求时，由后端服务器或Nginx本身生成一个唯一会话标识符（通常是一个随机字符串），并通过HTTP响应头（Set-Cookie）植入客户端浏览器。客户端在后续请求中会自动携带此Cookie。Nginx通过识别该Cookie，将请求路由至最初处理它的服务器。

配置方法
sticky指令的语法更丰富，常见的是cookie模式。

upstream backend {
    sticky cookie srv_id expires=1h domain=.example.com path=/;
    server 192.168.1.101:8080;
    server 192.168.1.102:8080;
    server 192.168.1.103:8080;
}

• cookie srv_id：指定Cookie的名称为srv_id。
• expires=1h：指定Cookie有效期为1小时。
• domain 和 path：定义Cookie的作用域。

执行过程

1. 客户端首次请求到达Nginx。
2. Nginx根据某种算法（如轮询）选择 一台后端服务器（例如 192.168.1.103）。
3. 转发 请求至 192.168.1.103。
4. 192.168.1.103 处理请求后，在响应头中添加 Set-Cookie: srv_id=001。
5. Nginx将此响应返回给客户端，客户端浏览器存储 该Cookie。
6. 后续客户端请求将自动携带 Cookie: srv_id=001。
7. Nginx读取 该Cookie，识别出后端服务器 001（对应 192.168.1.103），并将请求直接转发过去。

3. 核心差异对比

4. 如何选择：操作指南

根据上述差异，你可以遵循以下步骤做出决策：

1. 分析客户端网络环境

   • 检查 你的主要用户群体是否位于企业、学校或机构网络内部。如果是，大量用户很可能共享少数几个公网IP。此时避免使用ip_hash，否则会导致后端服务器负载严重不均。优先考虑 sticky cookie。

2. 评估应用的会话关键性

   • 确定 会话中断对用户体验的影响程度。例如，一个简单的信息展示网站，会话丢失可能只是让用户重新登录。而一个复杂的多步骤在线表单或购物车，会话中断意味着用户工作丢失。对于后者，需要更可靠的会话保持机制。

3. 检查后端服务器状态管理

   • 确认 你的后端应用如何存储会话数据。如果使用本地内存存储（如PHP的默认Session），那么会话与单台服务器强绑定，一旦服务器宕机或重启，会话立即丢失。ip_hash和sticky cookie都无法解决此问题。如果使用共享存储（如Redis、Memcached）存储会话，那么sticky cookie的灵活性优势将得到最大发挥。

4. 做出最终选择

   • 如果你的用户IP固定、网络结构简单、且会话中断可接受，ip_hash是简单有效的选择。
   • 如果你的应用面向移动互联网用户、或部署在NAT普遍的环境中、或要求高可用性和灵活的服务器伸缩，必须选择 sticky cookie方案。

验证与调试
配置完成后，可以使用以下方法验证：

• 查看上游连接：在Nginx服务器上执行 命令 nginx -T | grep -A 5 upstream，查看生效的配置块。
• 测试会话绑定：使用 curl 或浏览器开发者工具，模拟连续请求。

  # 测试首次请求，观察响应头中的Set-Cookie
  curl -v http://your.domain.com/path
  # 模拟后续请求，携带获取到的Cookie
  curl -v --cookie "srv_id=001" http://your.domain.com/path

• 监控后端状态：在后端服务器日志中，观察 来自同一客户端的请求是否被同一服务器处理。

5. 处理服务器下线
   • 当一台后端服务器需要维护下线时，sticky cookie方案可以更平滑地处理。你需要在Nginx配置中将该服务器标记为 down，并确保 共享会话存储中的相关会话数据已迁移或可在其他服务器访问。依赖该服务器的客户端会在下次请求时被分配到新服务器，可能需要重新登录，但不会影响其他会话。

     upstream backend {
     sticky cookie srv_id;
     server 192.168.1.101:8080;
     server 192.168.1.102:8080 down;
     server 192.168.1.103:8080;
     }