配置负载均衡需先明确业务需求再选算法：加权轮询按weight分配流量，适合硬件差异场景；ip_hash实现会话保持，但不支持weight混用；least_conn、hash $request_uri consistent、random two等适用于长连接、缓存一致性等特定场景。

配置负载均衡的后端调度算法，关键在于明确业务需求再选算法，然后在 upstream 块中写对参数。Nginx 原生支持轮询、加权轮询、ip_hash 等，不需要额外模块，配置生效快、运维成本低。

加权轮询：按服务器能力分配流量

适合后端服务器 CPU、内存或网络带宽存在明显差异的场景。比如一台 16C32G，一台 8C16G，一台 4C8G，可通过 weight 控制请求比例。

• weight 值是相对比例，不是绝对数值。weight=4 和 weight=2 的服务器，在一个完整周期里请求比为 2:1
• 配置示例：

  upstream app_servers {<br>    server 192.168.1.10:8080 weight=4;<br>    server 192.168.1.11:8080 weight=2;<br>    server 192.168.1.12:8080 weight=1;<br>}

• 权重不填默认为 1；weight=0 表示该节点不参与调度（但仍在健康检查范围内）
• 注意：加权轮询不感知实时负载，只保证长期统计意义上的比例，短时突发可能造成某台压力偏高

源地址哈希（ip_hash）：实现会话保持

客户端 IP 经哈希后固定映射到某台后端，适用于有状态服务（如未使用 Redis 共享 session 的老系统）。

• 必须放在 upstream 块顶层，不能和 weight 混用（Nginx 会报错）
• 配置示例：

  upstream app_sessions {<br>    ip_hash;<br>    server 192.168.1.20:8080;<br>    server 192.168.1.21:8080;<br>    server 192.168.1.22:8080;<br>}

• IPv6 地址也支持，Nginx 自动处理；但若前端有 CDN 或代理，真实客户端 IP 可能被覆盖，需配合 real_ip 模块和 set_real_ip_from 使用
• 某台服务器宕机时，其哈希槽位的用户请求会被重新分配，可能触发 session 丢失

其他常用算法补充说明

除上述两种外，实际中还有几个高频选项可按需启用：

• least_conn：优先分发到当前活跃连接数最少的服务器，适合长连接场景（如 WebSocket、FTP）
• hash $request_uri consistent：基于 URL 哈希，常用于缓存一致性，加 consistent 参数启用 Ketama 一致性哈希，增删节点时缓存命中率更稳
• random two：从上游随机挑两台，再选其中连接数少的——兼顾随机性与负载反馈，Nginx 1.19+ 支持

验证与调优建议

配置完别急着上线，先做基础验证：

• 用 nginx -t 检查语法，再 nginx -s reload 平滑加载
• 查看 access.log，用 awk + sort + uniq 统计各后端 IP 出现频次，确认比例是否符合预期
• 压测时观察各节点 CPU、连接数、响应时间，若某台 consistently 高于均值，考虑调整 weight 或换 least_conn
• 权重不是一劳永逸的值，建议结合监控（如 Prometheus + nginx-vts-exporter）定期复盘，动态优化