当前位置：首页 > news >正文

Nginx基于反向代理的负载均衡

news 2026/5/24 23:51:02

一、引言：从单点到集群，流量分发的艺术

当你的应用用户量从几百飙升到几万，单台服务器很快就会成为性能瓶颈，甚至面临宕机风险。此时，最直接有效的解决方案就是横向扩展——部署多台服务器组成集群。

但新问题随之而来：客户端如何知道该访问哪一台服务器？如果其中一台挂了怎么办？

答案就是“反向代理 + 负载均衡”。Nginx 完美地将这两个功能融为一体：

反向代理：作为统一入口，对外隐藏后端服务器集群。
负载均衡：作为智能调度员，将流量合理、高效地分发给集群中的每一台服务器。

本文将手把手教你配置 Nginx，打造一个高性能、高可用的服务集群。

💡核心价值：
掌握此技能，你就能轻松应对流量洪峰，告别单点故障，为业务稳定保驾护航！

二、核心基石：`upstream`模块

在 Nginx 中，负载均衡的能力由upstream（上游服务器）模块提供。它允许你定义一组后端服务器，并指定流量分发的策略。

基本语法

# 在 http 块内定义 upstream backend { server backend1.example.com weight=5; server backend2.example.com; server 192.0.0.1 backup; }

upstream backend:backend是这个服务器组的名字，后续在proxy_pass中会用到。
server: 定义一个后端服务器，可以是域名或IP+端口。
weight: 权重，默认为1。权重越高，接收的请求越多。
backup: 标记为备份服务器。只有当所有非备份服务器都不可用时，才会启用它。

三、四大主流负载均衡策略详解

Nginx 提供了多种算法来满足不同场景的需求。

策略一：轮询（Round Robin） - 默认策略

这是最简单也最常用的策略。Nginx 会按顺序将请求依次分发给服务器列表中的每一台。

upstream myapp { server 192.168.1.10:8080; server 192.168.1.11:8080; server 192.168.1.12:8080; }

效果：请求1 -> Server1, 请求2 -> Server2, 请求3 -> Server3, 请求4 -> Server1...

策略二：加权轮询（Weighted Round Robin）

当你的服务器硬件配置不同时（如一台16核，两台8核），可以通过权重让更强的机器承担更多流量。

upstream myapp { server 192.168.1.10:8080 weight=3; # 配置最强，承担3份流量 server 192.168.1.11:8080 weight=1; # 承担1份流量 server 192.168.1.12:8080 weight=1; # 承担1份流量 }

效果：每5个请求中，3个去Server1，1个去Server2，1个去Server3。

策略三：IP哈希（IP Hash）

此策略能保证同一个客户端IP的请求始终被转发到同一台后端服务器。这在需要会话保持（Session Sticky）但又不想使用共享Session存储的场景下非常有用。

upstream myapp { ip_hash; # 启用IP哈希 server 192.168.1.10:8080; server 192.168.1.11:8080; }

注意：如果后端服务器数量发生变化，原有的IP映射关系会被打乱。

策略四：最少连接（Least Connections）

Nginx 会将新请求分配给当前活跃连接数最少的服务器。这在处理长连接或请求处理时间差异较大的场景下更为公平。

upstream myapp { least_conn; # 启用最少连接 server 192.168.1.10:8080; server 192.168.1.11:8080; }

四、生产级完整配置示例

一个健壮的负载均衡配置，除了upstream，还需要包含健康检查、超时设置和必要的请求头。

http { # 定义上游服务器组 upstream backend_servers { # 使用加权轮询 server 192.168.1.10:8080 weight=3 max_fails=2 fail_timeout=30s; server 192.168.1.11:8080 weight=1 max_fails=2 fail_timeout=30s; # 备份服务器 server 192.168.1.12:8080 backup; } server { listen 80; server_name app.example.com; location / { # 反向代理到 upstream proxy_pass http://backend_servers; # ===== 必须设置的请求头 ===== 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 5s; # 与后端建立连接的超时 proxy_send_timeout 10s; # 发送请求给后端的超时 proxy_read_timeout 10s; # 读取后端响应的超时 } } }

关键参数解释

max_fails=2: 在fail_timeout时间内，如果尝试失败达到2次，则认为此服务器不可用。
fail_timeout=30s: 服务器被判定为不可用后的暂停服务时间（30秒后会再次尝试）。
backup: 仅在其他所有服务器都失效时才启用，用于兜底。

五、高级特性：被动健康检查与主动健康检查

上面的max_fails和fail_timeout属于被动健康检查——只有当有真实请求过来并失败时，Nginx 才会标记服务器为宕机。

对于更高要求的场景，Nginx Plus（商业版）或开源版本结合第三方模块（如nginx_upstream_check_module）可以实现主动健康检查，即 Nginx 主动定期向后端服务器发送探测请求（如/health），无需等待真实用户请求。

# (此为概念性配置，开源版需打补丁) upstream backend { server 192.168.1.10:8080; server 192.168.1.11:8080; check interval=3000 rise=2 fall=3 timeout=1000 type=http; check_http_send "GET /health HTTP/1.0\r\n\r\n"; check_http_expect_alive http_2xx http_3xx; }