Nginx Upstream了解一下

如果你的网站使用Nginx，一定很熟悉nginx配置吧，其中最常修改的莫过于 location，但是还有个非常重要的模块就是 upstream，今天就根据自己配置的经验及整理的资料做一总结。

Nginx 的 upstream 模块是负载均衡的核心组件，用于定义和管理后端服务器集群，实现请求分发、故障转移和高可用性。以下从核心功能、配置策略、高级特性及实际应用场景展开详解：

1 核心功能与基础配置

在 nginx.conf 配置文件中，server 模块通过 proxy_pass将特定的请求负载均衡到不同服务器上，简单配置及示意图如下。

upstream backend {
  # 负载均衡策略
  least_conn;
  # 主服务器配置
  server 192.168.1.101 weight=3 max_fails=2 fail_timeout=30s max_conns=200;
  server 192.168.1.102 weight=2 slow_start=60s;
  # ...其他配置
}

server {
  listen 80;
  location / {
    proxy_pass http://backend;
    proxy_set_header Host $host;
  }
}

1.1 定义服务器集群

upstream 块用于声明一组后端服务器（即上游服务器），支持域名、IP、端口及UNIX域套接字。

示例：

http {
  upstream backend {
    server backend1.example.com:8080 weight=3;
    server 192.168.1.102 max_fails=2 fail_timeout=30s;
    server unix:/tmp/backend.sock backup;
  }
}

• weight：权重控制请求分配比例（如权重3:2）。
• backup：标记为备用服务器，主节点失效时启用。
• max_fails 和 fail_timeout：定义健康检查阈值（如30秒内失败2次则标记为不可用）。

1.2 负载均衡策略

Nginx 支持多种负载均衡策略，其配置灵活且适用于不同场景。以下是主流策略及其配置方法：

1.2.1 轮询（Round Robin）

• 原理：按请求顺序依次分发到后端服务器，默认策略。
• 适用场景：服务器性能相近，无状态服务（如静态资源分发）。

upstream backend {
  server 192.168.1.101;
  server 192.168.1.102;
}

1.2.2 加权轮询（Weighted Round Robin）

• 原理：根据权重分配请求，权重越高分配的请求越多。
• 适用场景：服务器性能不均（如高配置机器权重设为3，低配设为1）。

upstream backend {
  server 192.168.1.101 weight=3;  # 处理约60%的请求
  server 192.168.1.102 weight=2;  # 处理约40%的请求
}

1.2.3 IP哈希（IP Hash）

• 原理：根据客户端IP的哈希值固定分配到同一服务器。
• 适用场景：需保持会话一致性的场景（如登录状态、购物车）。

upstream backend {
  ip_hash;
  server 192.168.1.101;
  server 192.168.1.102;
}

1.2.4 最少连接数（Least Connections）

• 原理：将请求分配给当前连接数最少的服务器。
• 适用场景：后端服务器处理时间差异较大（如长任务处理）。

upstream backend {
  least_conn;
  server 192.168.1.101;
  server 192.168.1.102;
}

1.2.5 随机（Random）

• 原理：随机选择服务器，可配合权重使用。
• 适用场景：需要简单随机分配的场景。

upstream backend {
  random;
  server 192.168.1.101;
  server 192.168.1.102;
}

1.2.6 Fair（响应时间优先）【扩展】

• 原理：根据服务器响应时间动态分配，响应快的优先。
• 适用场景：服务器性能差异大且需动态调整的场景。

（需安装nginx-upstream-fair模块）

upstream backend {
  fair;
  server 192.168.1.101;
  server 192.168.1.102;
}

1.2.7 URL哈希（URL Hash）【扩展】

• 原理：根据URL的哈希值固定分配到同一服务器。
• 适用场景：缓存优化（如CDN节点缓存相同资源）。

upstream backend {
  hash $request_uri;
  server 192.168.1.101;
  server 192.168.1.102;
}

2 server字段详解

Nginx 的 upstream 模块中，server 配置项是定义后端服务器的核心，支持多种参数以优化负载均衡、健康检查、故障转移等行为。以下从功能属性、配置示例及最佳实践展开深入分析：

2.1 核心配置属性

2.1.1 weight

• 功能：设置服务器的权重，决定请求分配比例。权重越高，分配的请求越多。
• 适用场景：后端服务器性能不均时，通过权重分配实现资源合理利用。

server 192.168.1.101 weight=5;  # 处理约83%的请求（5/(5+1)）
server 192.168.1.102 weight=1;  # 处理约17%的请求

2.1.2 max_fails 与 fail_timeout

• 功能：
  • max_fails：在 fail_timeout 时间内允许的失败次数，超过则标记服务器不可用。
  • fail_timeout：服务器被标记为不可用后的恢复时间。
• 适用场景：实现被动健康检查，自动剔除异常节点。

server 192.168.1.101 max_fails=3 fail_timeout=30s;  # 30秒内失败3次则暂停服务30秒

2.1.3 backup

• 功能：标记服务器为备用节点，仅当所有主节点不可用时启用。
• 适用场景：高可用架构中防止单点故障。

server 192.168.1.103 backup;  # 主节点失效时自动接管请求

2.1.4 down

• 功能：强制标记服务器为永久不可用，不参与负载均衡。
• 适用场景：配合 ip_hash 策略维护服务器状态。

server 192.168.1.104 down;  # 手动维护时临时下线节点

2.1.5 max_conns

• 功能：限制服务器的最大并发连接数，避免过载。
• 适用场景：保护低配置服务器或防止突发流量冲击。

server 192.168.1.101 max_conns=100;  # 最多允许100个并发连接

2.1.6 slow_start

• 功能：节点恢复后逐步增加权重，避免瞬时流量压垮刚恢复的服务器。
• 适用场景：节点恢复后的平滑启动。

server 192.168.1.101 slow_start=60s;  # 60秒内权重从0逐步恢复至设定值

2.1.7 resolve

• 功能：动态解析域名，支持DNS记录的实时更新（需Nginx Plus或第三方模块）。
• 适用场景：动态扩缩容场景，避免重启Nginx。

server backend.example.com resolve;  # 自动跟踪DNS变化

2.1.8 route

• 功能：自定义请求路由标签（需第三方模块）。
• 适用场景：复杂路由策略的定制化实现。

server 192.168.1.101 route=primary;  # 按标签路由请求

2.2 高级配置与优化

2.2.1 长连接优化

• 参数：keepalive、keepalive_timeout、keepalive_requests
• 功能：复用TCP连接，减少握手开销。
• 适用场景：高并发API服务或频繁短连接场景。

upstream backend {
  server 192.168.1.101;
  keepalive 100;                 # 空闲长连接最大数量
  keepalive_timeout 60s;         # 连接保持时间
  keepalive_requests 1000;       # 单个连接最大请求数
}

2.2.2 SSL/TLS 配置

• 参数：ssl、proxy_ssl_*
• 功能：与后端服务器建立加密连接。
• 适用场景：保护敏感数据传输（如支付接口）。

server backend.example.com:443 ssl;  # 启用SSL
proxy_ssl_session_reuse on;         # 复用SSL会话

2.2.3 IP哈希与会话保持

• 参数：ip_hash
• 功能：按客户端IP分配请求，确保会话一致性。
• 适用场景：需要维护Session状态的应用（如购物车）。

upstream backend {
  ip_hash;
  server 192.168.1.101;
  server 192.168.1.102;
}

2.3 配置示例与最佳实践

upstream backend {
  # 负载均衡策略
  least_conn;

  # 主服务器配置
  server 192.168.1.101 weight=3 max_fails=2 fail_timeout=30s max_conns=200;
  server 192.168.1.102 weight=2 slow_start=60s;

  # 备用服务器
  server 192.168.1.103 backup;

  # 长连接优化
  keepalive 50;
  keepalive_timeout 30s;
}

server {
  listen 80;
  location / {
    proxy_pass http://backend;
    proxy_set_header Host $host;
  }
}

最佳实践：

1. 权重分配：根据服务器CPU、内存性能动态调整权重。
2. 健康检查：结合 max_fails 和主动检查（如Nginx Plus）提高可靠性。
3. 备份节点：至少配置一个 backup 节点应对突发故障。
4. 版本兼容性：部分参数（如 resolve）需确认Nginx版本或模块支持。

3 高级配置与扩展功能

3.1 会话保持

• sticky 模块：通过Cookie实现会话跟踪，确保用户请求分发到同一服务器。

upstream backend {
  sticky cookie srv_id expires=1h;
  server 192.168.1.101;
  server 192.168.1.102;
}

• hash 算法：基于URL或自定义键值（如 $request_uri）哈希分配请求，适用于缓存优化。

3.2 健康检查与故障转移

• 被动检查：通过 max_fails 和 fail_timeout 自动剔除异常节点。
• 主动检查（需第三方模块）：如 nginx_upstream_check_module 定期探测服务器状态。

3.3 动态配置

支持通过API或工具动态添加/移除服务器，无需重启Nginx。

4 实际应用场景

4.1 无状态服务分发

使用轮询或加权轮询，适用于静态资源、API网关等场景。

4.2 会话敏感型应用

如电商购物车，采用 ip_hash 或 sticky 保持用户状态。

4.3 高可用架构

结合 backup 服务器和健康检查，实现故障自动切换。

4.4 缓存与CDN优化

使用 hash $request_uri 确保相同资源路由到同一节点，提升缓存命中率。

5 配置示例

http {
  upstream backend {
    least_conn;                # 最少连接策略
    server 192.168.1.101 weight=3 max_fails=2 fail_timeout=30s;
    server 192.168.1.102 weight=2;
    server 192.168.1.103 backup;  # 热备节点
  }

  server {
    listen 80;
    location / {
      proxy_pass http://backend;
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
    }
  }
}

6 使用注意事项

6.1 域名解析缓存

Nginx 启动时解析 upstream 中的域名并缓存，需重启或重载配置以更新DNS。

6.2 第三方模块依赖

如 fair（响应时间优先）和 url_hash 需额外安装模块。

6.3 会话一致性风险

动态扩缩容可能导致 ip_hash 失效，需结合分布式会话存储。 通过合理配置 upstream 模块，可显著提升系统的吞吐量、可用性和扩展性，适用于微服务、高并发API及分布式架构场景。

希望通过上面一些字段的介绍总结，对配置nginx负载均衡有所帮助。

参考：

• http-load-balancer
• ngx_http_upstream_module