Nginx基础教程（52）Nginx HTTP请求转发之开发upstream模块：Nginx负载均衡揭秘：如何让upstream模块成为你的流量指挥家

内容分享2周前发布吼吼爱吃葡萄

0 0 0

还在为服务器压力过大而烦恼吗？Nginx的upstream模块就像是聪明的交通警察，能把流量有序地引导到各个服务器，让你的网站运行如丝般顺滑。

一、Upstream是什么？为什么需要它？

想象一下，你是一家热门餐厅的领班。周末高峰期，顾客蜂拥而至，如果只有一个服务员，即使他三头六臂也难以应对。upstream模块就像是那位聪明的领班，它拥有一份服务员名单，知道如何合理分配顾客给不同的服务员，确保每位顾客都能得到及时服务。

从技术角度来说，upstream模块允许定义一组后端服务器（称为upstream服务器组），并通过proxy_pass等指令将请求转发到这些服务器。这种机制带来了几个显著优势：

高可用性：即使某台后端服务器宕机，其他服务器仍然可以处理请求可扩展性：可以轻松添加更多后端服务器来应对增加的负载维护便利：可以在不中断服务的情况下进行后端服务器维护

二、Upstream基础：如何配置你的第一个负载均衡

让我们从最简单的upstream配置开始，先来看一个基本示例：



upstream backend {
    server 172.16.1.3;
    server 172.16.1.4;
}
 
server {
    location / {
        proxy_pass http://backend;
    }
}

在这个配置中，我们定义了一个名为”backend”的服务器组，包含两个服务器。当用户访问网站时，Nginx会按照轮询方式将请求依次分发到这两个服务器。

是不是很简单？但这只是upstream的基础用法。实际上，upstream提供了丰富的参数来满足各种复杂场景的需求。

三、Upstream参数详解：打造专属负载均衡策略

upstream服务器的参数可以比作给服务员分配工作的具体规则，比如哪个服务员经验丰富多分配些客人，哪个是新手少分配些，哪个是备用人员只在忙时帮忙。

3.1 权重（weight） – 能者多劳



upstream backend {
    server 172.16.1.3 weight=1;
    server 172.16.1.4 weight=2;
}

在这个例子中，172.16.1.4服务器接收的请求量将是172.16.1.3服务器的两倍。weight参数设置了服务器的权重，默认值为1。权重越高，被分配的请求越多。这在服务器性能不均衡的环境中特别有用，可以让性能更强的服务器处理更多请求。

3.2 健康检查 – 避免把请求发给”病人”



upstream backend {
    server backend1.example.com max_fails=3 fail_timeout=30s;
    server backend2.example.com max_fails=3 fail_timeout=30s;
}

max_fails和fail_timeout参数用于健康检查。max_fails指定了Nginx与服务器通信的失败尝试次数，默认值为1。fail_timeout设定了统计失败尝试次数的时间段和服务器被认为不可用的时间，默认值为10秒。

当服务器失败次数达到max_fails时，在接下来的fail_timeout时间内，Nginx会认为该服务器不可用，不再将请求转发给它。

3.3 备份服务器 – 关键时刻的救星



upstream backend {
    server backend1.example.com;
    server backend2.example.com;
    server backup.example.com backup;
}

backup参数将服务器标记为备用服务器。当所有主服务器都不可用时，请求才会被传递给备用服务器。这为系统提供了额外的容错能力，确保即使在高峰故障期也能保持基本服务。

四、负载均衡策略：upstream的智能调度算法

upstream模块支持多种负载均衡策略，每种策略适用于不同的场景，就像不同的交通规则适用于不同路况一样。

4.1 轮询（Round Robin） – 公平的轮流制

轮询是upstream的默认分配方式，每个请求按时间顺序逐一分配到不同的后端服务器。如果某台服务器宕机，会自动被剔除，剩下的继续轮询。



upstream backend {
    server 172.16.1.3;
    server 172.16.1.4;
}

4.2 ip_hash – 保持会话的连续性



upstream backend {
    ip_hash;
    server 172.16.1.3;
    server 172.16.1.4;
}

ip_hash策略按照访问IP的hash结果分配请求，这样同一客户端的连续请求会被分发到同一台服务器，解决了session共享的问题。如果服务器不可用，该客户端的请求会被传递给其他服务器。

4.3 最少连接（least_conn） – 能者多劳的智能版



upstream backend {
    least_conn;
    server 172.16.1.3;
    server 172.16.1.4;
}

least_conn策略把请求转发给连接数较少的后端服务器。它考虑了各服务器的当前负载，而不是简单轮询，更适合处理长连接应用，如数据库连接、WebSocket等。

4.4 一致性hash – 缓存友好的策略



upstream backend {
    hash $request_uri;
    server 172.16.1.3;
    server 172.16.1.4;
}

一致性hash策略确保相同URL的请求总是被路由到同一台服务器，这在后端服务器有缓存时特别有用。它可以提高缓存命中率，减少重复计算。

五、进阶技巧：upstream性能优化配置

5.1 保持连接（keepalive） – 减少连接开销



upstream http_backend {
    server 172.16.1.3;
    server 172.16.1.4;
    
    keepalive 32;
}
 
server {
    location / {
        proxy_pass http://http_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}

keepalive指令激活对上游服务器连接的缓存。它设置了每个worker进程与后端服务器保持连接的最大数量，减少频繁建立和关闭TCP连接的开销，显著提升性能。

5.2 缓冲区优化 – 处理大响应



location / {
    proxy_pass http://backend;
    proxy_buffering on;
    proxy_buffer_size 4k;
    proxy_buffers 8 4k;
    proxy_busy_buffers_size 16k;
}

这些缓冲区指令优化了Nginx处理上游服务器响应的方式：

proxy_buffer_size：设置用于保存响应头的缓冲区大小proxy_buffers：设置用于读取响应的缓冲区数量和大小proxy_busy_buffers_size：限制正在被发送到客户端的缓冲区大小

合理配置这些参数可以优化大响应（如文件下载）的处理效率。

六、实战示例：构建高可用Web架构

假设我们要为一个电商网站构建负载均衡架构，要求是：高性能、高可用、支持会话保持。以下是完整配置示例：



# 定义上游服务器组
upstream backend_servers {
    # 使用最少连接负载均衡策略
    least_conn;
    
    # 主服务器，权重更高，处理更多请求
    server 172.16.1.10 weight=3 max_fails=3 fail_timeout=30s;
    server 172.16.1.11 weight=3 max_fails=3 fail_timeout=30s;
    
    # 辅助服务器，权重较低
    server 172.16.1.12 weight=1 max_fails=3 fail_timeout=30s;
    
    # 备份服务器，只在所有主服务器不可用时使用
    server 172.16.1.13 backup;
    
    # 保持连接优化
    keepalive 64;
}
 
# 静态资源服务器组
upstream static_servers {
    server 172.16.2.10;
    server 172.16.2.11;
    
    # 静态资源使用轮询即可
}
 
server {
    listen 80;
    server_name example.com;
    
    # 动态请求处理
    location / {
        proxy_pass http://backend_servers;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        
        # 超时设置
        proxy_connect_timeout 2s;
        proxy_send_timeout 5s;
        proxy_read_timeout 5s;
    }
    
    # 静态请求处理
    location /static/ {
        proxy_pass http://static_servers;
        proxy_buffering on;
        proxy_cache_valid 200 1d;
    }
    
    # 健康检查端点
    location /nginx_status {
        stub_status;
        allow 172.16.0.0/16;
        deny all;
    }
}

这个配置实现了：

智能负载均衡：使用最少连接策略，确保请求被分配到负载较轻的服务器权重分配：给性能更强的服务器分配更高权重故障转移：通过max_fails和fail_timeout检测故障服务器备份机制：在主服务器全部故障时启用备份服务器连接优化：使用keepalive减少TCP连接开销动静分离：动态请求和静态请求分别处理超时控制：设置合理的超时时间避免请求堆积

七、动态Upstream配置：无需重启的服务器管理

Nginx还提供了动态配置上游服务器的能力，无需重启Nginx服务。这通过ngx_http_upstream_conf_module模块（在1.13.3版本后被ngx_http_api_module取代）实现。

配置示例：



upstream backend {
    zone upstream_backend 64k;
    server 172.16.1.3;
    server 172.16.1.4;
}
 
server {
    location /upstream_conf {
        upstream_conf;
        allow 127.0.0.1;
        deny all;
    }
}

通过HTTP接口，我们可以动态管理上游服务器：

查看服务器状态：http://127.0.0.1/upstream_conf?upstream=backend添加服务器：http://127.0.0.1/upstream_conf?add=&upstream=backend&server=172.16.1.5:8080删除服务器：http://127.0.0.1/upstream_conf?remove=&upstream=backend&id=2设置服务器为drain模式：http://127.0.0.1/upstream_conf?upstream=backend&id=2&drain=

这种动态管理能力在自动化部署和弹性扩展场景中非常有用，可以根据负载情况自动调整后端服务器数量。