Nginx负载均衡需按业务特性选择调度算法：轮询/加权轮询适配能力差异，IP/Cookie哈希保障会话一致性，最少连接应对长连接，响应时间感知需Nginx Plus或扩展实现，并必须配合健康检查与容错配置。
直接在 upstream 块中指定调度算法，并结合服务器参数和健康检查机制，就能实现有效的负载调度优化。关键不在于堆砌功能，而在于匹配业务实际——比如有状态服务必须考虑会话一致性，长连接服务得关注活跃连接数，性能差异大的集群则需权重干预。
轮询与加权轮询：适配服务器能力差异
轮询是默认策略，适合后端性能均等、无状态的服务（如静态资源或RESTful API）。但若服务器CPU核数、内存或部署环境不同，单纯轮询容易导致负载倾斜。
- 用
weight显式分配流量比例，例如server 192.168.1.10 weight=5和server 192.168.1.11 weight=3，大致按 5:3 分流 - 权重值建议基于压测结果设定：先单独测试各节点吞吐量（如QPS），再按比例折算为整数权重
- 避免权重设得过高（如超过10），否则小故障可能造成大量请求集中失败；可搭配
max_fails=2 fail_timeout=15s自动隔离异常节点
IP Hash 与 Cookie Hash：保障会话连续性
当后端未共享 Session（如传统 Tomcat 部署），用户登录后跳转到不同机器会导致登出。此时需绑定客户端到固定后端。
-
ip_hash最简方案，但 NAT 环境下多个用户共用一个出口 IP，易造成单点压力；且增减节点会打乱哈希映射 - 更稳妥的是用
hash $cookie_sessionid consistent;，基于用户 Cookie 中的 session ID 做一致性哈希，扩容缩容影响更小 - 若使用了反向代理（如 CDN 或 WAF），记得传真实 IP：
proxy_set_header X-Forwarded-For $remote_addr;，并在 hash 时改用$http_x_forwarded_for
最少连接与响应时间感知：应对动态负载
轮询和权重都是静态策略，无法反映实时压力。对 WebSocket、文件上传、或处理耗时不均的接口，应转向动态算法。
-
least_conn优先发往当前活跃连接最少的节点，适合长连接场景，配置只需在 upstream 中加一行 - 原生 Nginx 不支持响应时间加权（least_time），该功能属 Nginx Plus 商业版；开源版可通过
fair模块（需编译）或 Lua 脚本+自定义 upstream 实现类似逻辑 - 无论选哪种动态策略，都必须配合健康检查：启用
max_fails+fail_timeout，或在 Plus 版中配置主动health_check探针
组合健壮性配置：让策略真正落地
再好的调度算法，没有容错机制也难扛住生产波动。几个不可省略的加固点：
- 每个
server行加上max_fails=3 fail_timeout=30s，避免单次超时就踢出节点 - 关键服务添加
backup服务器，主集群全挂时自动切流，例如server 192.168.1.200:8080 backup; - 用
zone backend 64k;开启共享内存，使多 worker 进程间状态同步，防止健康检查判断不一致 - 日志中开启
$upstream_addr和$upstream_response_time，用于事后分析调度是否均衡、是否存在慢节点
