Nginx配置文件使用与负载均衡实现详解

Nginx作为高性能的Web服务器和反向代理服务器，其配置灵活性和负载均衡能力是核心优势。以下是Nginx配置文件的详细使用方法和4种常用负载均衡实现方式。

一、Nginx配置文件基础

1. 配置文件结构


# 全局块：配置影响nginx全局的指令
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
# events块：配置影响nginx服务器与用户的网络连接
events {
    worker_connections 1024;
    use epoll;
}
# http块：配置代理、缓存、日志等绝大多数功能
http {
    # server块：配置虚拟主机的相关参数
    server {
        # location块：配置请求的路由
        location / {
            root /usr/share/nginx/html;
        }
    }
}
# 全局块：配置影响nginx全局的指令
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;

# events块：配置影响nginx服务器与用户的网络连接
events {
    worker_connections 1024;
    use epoll;
}

# http块：配置代理、缓存、日志等绝大多数功能
http {
    # server块：配置虚拟主机的相关参数
    server {
        # location块：配置请求的路由
        location / {
            root /usr/share/nginx/html;
        }
    }
}
# 全局块：配置影响nginx全局的指令
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;

# events块：配置影响nginx服务器与用户的网络连接
events {
    worker_connections 1024;
    use epoll;
}

# http块：配置代理、缓存、日志等绝大多数功能
http {
    # server块：配置虚拟主机的相关参数
    server {
        # location块：配置请求的路由
        location / {
            root /usr/share/nginx/html;
        }
    }
}

2. 核心配置指令

指令	作用	示例
`listen`	监听端口	`listen 80;`
`server_name`	域名匹配	`server_name example.com;`
`root`	站点根目录	`root /data/www;`
`location`	请求路由	`location /images/ { ... }`
`proxy_pass`	反向代理	`proxy_pass http://backend;`
`error_page`	错误页面	`error_page 404 /404.html;`

3. 配置文件检查与重载


# 检查配置语法
nginx -t
# 重新加载配置（不中断服务）
nginx -s reload
# 检查配置语法
nginx -t

# 重新加载配置（不中断服务）
nginx -s reload
# 检查配置语法
nginx -t

# 重新加载配置（不中断服务）
nginx -s reload

二、Nginx实现负载均衡的4种常用方式

1. 轮询（Round Robin） – 默认方式


http {
    upstream backend {
        server backend1.example.com;
        server backend2.example.com;
        server backend3.example.com;
    }
    server {
        location / {
            proxy_pass http://backend;
        }
    }
}
http {
    upstream backend {
        server backend1.example.com;
        server backend2.example.com;
        server backend3.example.com;
    }

    server {
        location / {
            proxy_pass http://backend;
        }
    }
}
http {
    upstream backend {
        server backend1.example.com;
        server backend2.example.com;
        server backend3.example.com;
    }

    server {
        location / {
            proxy_pass http://backend;
        }
    }
}

特点：

请求按时间顺序分配到不同服务器
适合服务器性能相近的场景
默认权重(weight)为1

2. 加权轮询（Weighted Round Robin）


upstream backend {
    server backend1.example.com weight=3;
    server backend2.example.com weight=2;
    server backend3.example.com weight=1;
}
upstream backend {
    server backend1.example.com weight=3;
    server backend2.example.com weight=2;
    server backend3.example.com weight=1;
}
upstream backend {
    server backend1.example.com weight=3;
    server backend2.example.com weight=2;
    server backend3.example.com weight=1;
}

特点：

通过weight参数分配请求比例
适合服务器性能不均的场景
权重越高分配的请求越多

3. IP哈希（IP Hash）


upstream backend {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}
upstream backend {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}
upstream backend {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}

特点：

同一客户端IP始终访问同一后端服务器
解决session保持问题
服务器宕机会自动剔除

4. 最少连接（Least Connections）


upstream backend {
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}
upstream backend {
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}
upstream backend {
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}

特点：

优先将请求发给当前连接数最少的服务器
适合请求处理时间长短不一的场景
需要Nginx主动监测后端连接数

三、高级负载均衡配置

1. 健康检查机制


upstream backend {
    server backend1.example.com max_fails=3 fail_timeout=30s;
    server backend2.example.com max_fails=3 fail_timeout=30s;
    # 被动健康检查
    server backend3.example.com backup;  # 备用服务器
}
upstream backend {
    server backend1.example.com max_fails=3 fail_timeout=30s;
    server backend2.example.com max_fails=3 fail_timeout=30s;

    # 被动健康检查
    server backend3.example.com backup;  # 备用服务器
}
upstream backend {
    server backend1.example.com max_fails=3 fail_timeout=30s;
    server backend2.example.com max_fails=3 fail_timeout=30s;

    # 被动健康检查
    server backend3.example.com backup;  # 备用服务器
}

2. 长连接优化


upstream backend {
    server 192.168.1.101:8080;
    server 192.168.1.102:8080;
    keepalive 32;  # 保持的连接数
    keepalive_timeout 60s;  # 保持时间
}
server {
    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}
upstream backend {
    server 192.168.1.101:8080;
    server 192.168.1.102:8080;

    keepalive 32;  # 保持的连接数
    keepalive_timeout 60s;  # 保持时间
}

server {
    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}
upstream backend {
    server 192.168.1.101:8080;
    server 192.168.1.102:8080;

    keepalive 32;  # 保持的连接数
    keepalive_timeout 60s;  # 保持时间
}

server {
    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}

3. 会话保持方案


# 方案1：使用cookie插入
upstream backend {
    sticky cookie srv_id expires=1h domain=.example.com path=/;
    server backend1.example.com;
    server backend2.example.com;
}
# 方案2：使用route参数
upstream backend {
    sticky route $http_cookie_jsessionid;
    server backend1.example.com route=a;
    server backend2.example.com route=b;
}
# 方案1：使用cookie插入
upstream backend {
    sticky cookie srv_id expires=1h domain=.example.com path=/;
    server backend1.example.com;
    server backend2.example.com;
}

# 方案2：使用route参数
upstream backend {
    sticky route $http_cookie_jsessionid;
    server backend1.example.com route=a;
    server backend2.example.com route=b;
}
# 方案1：使用cookie插入
upstream backend {
    sticky cookie srv_id expires=1h domain=.example.com path=/;
    server backend1.example.com;
    server backend2.example.com;
}

# 方案2：使用route参数
upstream backend {
    sticky route $http_cookie_jsessionid;
    server backend1.example.com route=a;
    server backend2.example.com route=b;
}

四、负载均衡策略对比

策略	优点	缺点	适用场景
轮询	实现简单，绝对公平	不考虑服务器性能差异	服务器性能相近
加权轮询	考虑服务器性能差异	实时负载情况不敏感	服务器性能不均
IP哈希	会话保持良好	可能导致负载不均	需要session保持
最少连接	动态负载均衡	实现复杂度较高	请求处理时间差异大

五、生产环境最佳实践

1. 多级负载均衡架构


# 第一层：DNS轮询
# 配置多个A记录指向不同Nginx入口
# 第二层：Nginx反向代理
upstream frontend {
    server nginx1.example.com;
    server nginx2.example.com;
}
# 第三层：应用服务器集群
upstream app_servers {
    least_conn;
    server app1.example.com:8080;
    server app2.example.com:8080;
    server app3.example.com:8080;
}
# 第一层：DNS轮询
# 配置多个A记录指向不同Nginx入口

# 第二层：Nginx反向代理
upstream frontend {
    server nginx1.example.com;
    server nginx2.example.com;
}

# 第三层：应用服务器集群
upstream app_servers {
    least_conn;
    server app1.example.com:8080;
    server app2.example.com:8080;
    server app3.example.com:8080;
}
# 第一层：DNS轮询
# 配置多个A记录指向不同Nginx入口

# 第二层：Nginx反向代理
upstream frontend {
    server nginx1.example.com;
    server nginx2.example.com;
}

# 第三层：应用服务器集群
upstream app_servers {
    least_conn;
    server app1.example.com:8080;
    server app2.example.com:8080;
    server app3.example.com:8080;
}

2. 灰度发布配置


upstream production {
    server app-prod1.example.com;
    server app-prod2.example.com;
}
upstream staging {
    server app-stage.example.com;
}
split_clients "${remote_addr}AAA" $variant {
    5%     staging;    # 5%流量到测试环境
    95%    production; # 95%流量到生产环境
}
server {
    location / {
        proxy_pass http://$variant;
    }
}
upstream production {
    server app-prod1.example.com;
    server app-prod2.example.com;
}

upstream staging {
    server app-stage.example.com;
}

split_clients "${remote_addr}AAA" $variant {
    5%     staging;    # 5%流量到测试环境
    95%    production; # 95%流量到生产环境
}

server {
    location / {
        proxy_pass http://$variant;
    }
}
upstream production {
    server app-prod1.example.com;
    server app-prod2.example.com;
}

upstream staging {
    server app-stage.example.com;
}

split_clients "${remote_addr}AAA" $variant {
    5%     staging;    # 5%流量到测试环境
    95%    production; # 95%流量到生产环境
}

server {
    location / {
        proxy_pass http://$variant;
    }
}

3. 监控与日志


# 访问日志记录上游服务器
log_format upstream_log '$remote_addr - $remote_user [$time_local] '
                       '"$request" $status $body_bytes_sent '
                       '"$http_referer" "$http_user_agent" '
                       'upstream: $upstream_addr';
# 开启状态监控
server {
    location /nginx_status {
        stub_status on;
        access_log off;
        allow 192.168.1.0/24;
        deny all;
    }
}
# 访问日志记录上游服务器
log_format upstream_log '$remote_addr - $remote_user [$time_local] '
                       '"$request" $status $body_bytes_sent '
                       '"$http_referer" "$http_user_agent" '
                       'upstream: $upstream_addr';

# 开启状态监控
server {
    location /nginx_status {
        stub_status on;
        access_log off;
        allow 192.168.1.0/24;
        deny all;
    }
}
# 访问日志记录上游服务器
log_format upstream_log '$remote_addr - $remote_user [$time_local] '
                       '"$request" $status $body_bytes_sent '
                       '"$http_referer" "$http_user_agent" '
                       'upstream: $upstream_addr';

# 开启状态监控
server {
    location /nginx_status {
        stub_status on;
        access_log off;
        allow 192.168.1.0/24;
        deny all;
    }
}

六、常见问题解决方案

1. 负载不均问题

排查方法：


  # 查看各worker进程连接数
  watch -n 1 "ps -eo pid,cmd | grep nginx | grep -v grep"
  # 查看各worker进程连接数
  watch -n 1 "ps -eo pid,cmd | grep nginx | grep -v grep"
  # 查看各worker进程连接数
  watch -n 1 "ps -eo pid,cmd | grep nginx | grep -v grep"

解决方案：
调整权重(weight)参数
改用least_conn策略
检查后端服务器响应时间差异

2. 502 Bad Gateway错误

检查步骤：


  # 增加调试信息
  proxy_next_upstream error timeout invalid_header http_500 http_502;
  proxy_intercept_errors on;
  error_log /var/log/nginx/error.log debug;
  # 增加调试信息
  proxy_next_upstream error timeout invalid_header http_500 http_502;
  proxy_intercept_errors on;
  error_log /var/log/nginx/error.log debug;
  # 增加调试信息
  proxy_next_upstream error timeout invalid_header http_500 http_502;
  proxy_intercept_errors on;
  error_log /var/log/nginx/error.log debug;

常见原因：
后端服务不可用
代理超时设置过短
请求头过大

3. 性能调优参数


# 调整缓冲区
proxy_buffers 16 32k;
proxy_buffer_size 64k;
# 调高超时时间
proxy_connect_timeout 75s;
proxy_send_timeout 300s;
proxy_read_timeout 300s;
# 开启gzip压缩
gzip on;
gzip_min_length 1k;
gzip_types text/plain application/xml;
# 调整缓冲区
proxy_buffers 16 32k;
proxy_buffer_size 64k;

# 调高超时时间
proxy_connect_timeout 75s;
proxy_send_timeout 300s;
proxy_read_timeout 300s;

# 开启gzip压缩
gzip on;
gzip_min_length 1k;
gzip_types text/plain application/xml;
# 调整缓冲区
proxy_buffers 16 32k;
proxy_buffer_size 64k;

# 调高超时时间
proxy_connect_timeout 75s;
proxy_send_timeout 300s;
proxy_read_timeout 300s;

# 开启gzip压缩
gzip on;
gzip_min_length 1k;
gzip_types text/plain application/xml;