配置负载均衡需先明确业务需求再选算法：加权轮询按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）定期复盘，动态优化
