关键在于匹配业务真实负载特征：无状态服务用轮询或加权轮询，会话保持服务用ip_hash或cookie_hash，长连接服务用least_conn；配合max_fails、proxy_next_upstream和主动健康检查实现故障自愈。
优化 Nginx 高可用负载均衡器的请求分发策略，关键不在堆参数，而在于匹配业务真实负载特征。选对策略比调参更重要，再配合适当的健康保障机制，才能让集群稳得住、扛得久、扩得快。
按业务状态选核心分发策略
不同业务对“均衡”的定义完全不同：
- 无状态服务（如 API 查询、静态资源）：优先用轮询或加权轮询。轮询适合服务器配置完全一致；若混用新旧机器或存在性能差异（比如一台 16 核、一台 8 核），直接设 weight=2 和 weight=1，流量按比例切分，避免弱机过载。
- 需会话保持的服务（如登录态、购物车、文件上传）：必须启用 ip_hash。注意它不解决 NAT 环境下 IP 集中问题，若用户大量来自企业出口或运营商 NAT 池，可考虑配合 $binary_remote_addr 降低哈希碰撞，或改用 cookie 哈希（需 ngx_http_upstream_cookie_module）。
- 长连接或处理时长波动大的服务（如 WebSocket、音视频转码、报表导出）：least_conn 更可靠。它看的是当前活跃连接数，而非请求数，能自然避开正在处理大任务的节点，防止请求堆积。
让策略真正“活”起来：健康检查与故障隔离
没有健康检查的负载均衡只是假高可用。Nginx 默认只做被动检测（连接失败才剔除），建议主动补全：
- 在 upstream 中为每台 server 显式配置 max_fails=3 fail_timeout=30s，连续 3 次探活失败后，30 秒内不再转发请求。
- 搭配 location 块里的 proxy_next_upstream error timeout http_500 http_502 http_503 http_504，让网关在后端返回错误或超时时自动重试另一台，提升单次请求成功率。
- 若需更精细探测（如检查特定 HTTP 状态码或响应内容），可借助 nginx-plus 商业版，或用 OpenResty + Lua 自定义健康检查逻辑。
应对真实流量波动：权重动态化与灰度控制
静态权重在发布、扩容、突发流量时容易失准：
- 上线新版本服务时，不要一次性切全量。先设 weight=1，老服务 weight=9，观察日志和错误率，逐步调高新服务权重。
- 用 Prometheus + Grafana 监控各后端的 request_time、upstream_response_time、active connections。当某台 CPU 或响应延迟持续偏高，可通过 API 或配置热重载临时调低其 weight，实现“软降级”。
- 对地域敏感业务（如 CDN 回源），可在 upstream 中结合 geo 模块或 map 指令，按 $remote_addr 所属区域选择不同 server 组，做到就近接入。
底层支撑不能拖后腿
再好的策略也跑在系统上：
- worker_processes 设为 auto，确保每个 CPU 核心一个 worker 进程。
- 调大 worker_connections（如 10240），并同步调整系统级限制：ulimit -n 和 /etc/security/limits.conf 中的 nofile。
- 启用 reuseport（需 Linux 3.9+），让多个 worker 进程能独立监听同一端口，减少惊群效应，提升新建连接吞吐。
