在分布式系统中Nginx 负载均衡是入门必学、线上必用的核心技能。这篇文章用“实战配置 场景选型”的思路帮你快速掌握。 一、负载均衡做什么当你有多台后端服务器时Nginx 作为入口把外部请求按一定规则分发到不同后端实现- 水平扩展加机器就能扛更多流量。- 高可用某台后端挂了自动切到健康节点。- 灵活调度按性能、会话、连接数等策略分发。核心模块就两块-ngx_http_upstream_module定义后端服务器组upstream。-ngx_http_proxy_module把请求转发过去proxy_pass。⚙️ 二、基础配置骨架一个最小可用的负载均衡配置长这样http {# 1. 定义后端服务器组upstream myapp {server 192.168.1.101:8080;server 192.168.1.102:8080;server 192.168.1.103:8080;}server {listen 80;server_name your-domain.com;location / {# 2. 反向代理到 upstreamproxy_pass http://myapp;# 3. 透传关键头部真实IP、Host等proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;}}}-upstream 定义一组后端proxy_pass 引用组名即可实现负载均衡。- 默认策略是加权轮询weight1请求依次分发到 101→102→103→101… 三、常用负载均衡策略不同场景选不同策略都在 upstream 里配1. 轮询Round Robin—— 默认不加任何策略就是轮询请求依次轮流发到各后端。适合后端配置相近、无状态的短请求。2. 加权轮询Weighted Round Robinupstream myapp {server 192.168.1.101:8080 weight3; # 高配机多扛流量server 192.168.1.102:8080 weight2; # 中配server 192.168.1.103:8080 weight1; # 低配/测试机}按权重比例分发weight 越高分到的请求越多。常用于机器配置不均、灰度发布等场景。3. IP 哈希IP Hash—— 会话保持upstream myapp {ip_hash; # 同一客户端 IP 固定打到同一后端server 192.168.1.101:8080;server 192.168.1.102:8080;}基于客户端 IP 做哈希确保同一用户请求落到同一台后端。适合 Session 未共享、有本地缓存的场景。注意一般不与 weight 混用且后端增减会导致部分会话失效。4. 最少连接数Least Connectionsupstream myapp {least_conn;server 192.168.1.101:8080;server 192.168.1.102:8080;}优先发给当前活跃连接数最少的后端。适合请求处理时间差异大、长耗时任务多的场景如大文件上传、复杂计算。5. 其他高级策略- URL 哈希hash $request_uri相同 URL 打到同一后端提高缓存命中。- fair / 响应时间优先多为第三方模块按响应速度动态调度非 Nginx 官方内置。 四、健康检查与故障转移生产环境必须配否则后端挂了 Nginx 还会继续转发造成 502/504。被动检查Nginx 开源版标配upstream myapp {server 192.168.1.101:8080 max_fails3 fail_timeout30s;server 192.168.1.102:8080 max_fails3 fail_timeout30s;}location / {proxy_pass http://myapp;# 连接错误/超时自动重试到下一台也可加上 http_500/502/503proxy_next_upstream error timeout;}-max_fails在fail_timeout 内失败几次标记为不可用。-fail_timeout标记不可用后的停用时间过后自动探活恢复。- 默认只对网络级错误连接拒绝、超时计数HTTP 5xx 不算失败可通过proxy_next_upstream 扩展。主动健康检查商业版/Tengine开源 Nginx 原生不支持主动探活但 Tengine / Nginx Plus 支持upstream myapp {zone myapp 64k;server 192.168.1.101:8080;server 192.168.1.102:8080;}server {location / {proxy_pass http://myapp;health_check interval5s fails3 passes2;}}定期主动发请求检查后端健康比被动更及时。 五、生产级完整示例结合策略、健康检查和超时控制的实用配置http {upstream backend {# 策略最少连接带权重least_conn;# 主节点server 192.168.1.101:8080 weight3 max_fails3 fail_timeout30s;server 192.168.1.102:8080 weight2 max_fails3 fail_timeout30s;# 备份节点主节点全挂时启用server 192.168.1.103:8080 backup;}server {listen 80;server_name api.your-app.com;location / {proxy_pass http://backend;# 透传真实 IP/Hostproxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;# 超时控制按后端 P99 响应调整proxy_connect_timeout 5s;proxy_send_timeout 10s;proxy_read_timeout 60s;# 错误重试网络错 5xx最多试 2 次proxy_next_upstream error timeout http_500 http_502 http_503;proxy_next_upstream_tries 2;}}} 六、常见坑与避雷1. Session 共享用了ip_hash 就别随便增删后端节点推荐直接用 Redis 集中存 Session更灵活。2. 健康检查不够细被动检查依赖真实流量关键时刻可能不及时重要业务考虑 Tengine / Nginx Plus 主动检查或接入外部服务发现。3. 超时设太小导致大量 502/504建议按后端接口 P99 响应时间的 1.52 倍配置超时。4. 重试非幂等请求proxy_next_upstream 默认只对 GET/HEAD 等幂等方法生效POST 重试可能导致重复下单慎配。如果你告诉我你的具体场景比如 Java/Go 应用、是否有 Session、想用什么策略我可以给你一份更贴合业务的精简配置。