核心是组合被动与主动健康检查：被动用max_fails/fail_timeout摘除故障节点，主动用/health探针验证业务就绪；辅以least_conn算法、收紧超时参数及后端健康接口联动。
用 Nginx 实现请求动态负载，核心是让请求分发行为能随后端服务器状态或实时指标自动调整，而不是静态写死。这主要依赖健康检查机制 + 动态算法选择，不是靠手动改配置来“实时响应”。
启用主动健康检查，实现故障自动剔除与恢复
Nginx 开源版本身不支持 HTTP 级主动探活（如定期 GET /health），但可通过 第三方模块 nginx_upstream_check_module 或升级到 Nginx Plus 实现。开源常用替代方案是结合 max_fails/fail_timeout 参数，依靠反向代理失败反馈被动判断：
- 每次 proxy_pass 请求失败（超时、5xx）计一次失败；
- 当某 server 在 fail_timeout 时间内累计失败达 max_fails 次，Nginx 就将其标记为不可用；
- 过了 fail_timeout 后，Nginx 会尝试重新转发请求——若成功则自动恢复，失败则继续剔除。
示例配置：
upstream backend {server 192.168.1.101:8080 max_fails=3 fail_timeout=30s;
server 192.168.1.102:8080 max_fails=3 fail_timeout=30s;
}
选用 least_conn 算法应对长连接场景
轮询和加权轮询只看请求次数，不感知连接压力。而 least_conn 会实时统计每个后端的活跃连接数，把新请求优先交给当前连接最少的机器——这对 WebSocket、HTTP/2 或上传类长连接业务更公平。
- 适合后端处理耗时差异大、连接生命周期长的场景；
- 无需额外参数，只需在 upstream 块中加入 least_conn; 指令；
- 注意：它统计的是 Nginx 与后端之间的连接数，不是后端应用内部线程数。
配置片段：
upstream backend {least_conn;
server 192.168.1.101:8080;
server 192.168.1.102:8080;
}
通过 weight 动态调整流量比例（需配合外部干预）
weight 本身是静态值，但“动态”可体现在运维层面：比如监控发现某台机器 CPU 持续高于 80%，就通过自动化脚本修改其 weight 值并 reload Nginx。虽然 reload 有毫秒级中断，但比完全停机友好得多。
- weight=1 是基准，weight=5 表示该节点接收约 5 倍于 weight=1 的请求量；
- 可搭配 backup 标记做灰度切换，例如先设 weight=0，观察日志再逐步调高；
- 避免频繁 reload，建议用配置模板 + Ansible 或 Consul Template 等工具批量管理。
ip_hash 不是动态负载，而是会话固化策略
ip_hash 看似“固定”，实则是为解决 session 共享问题而设计的确定性分配。它不参与动态负载决策，反而会削弱负载均衡效果——比如某 IP 段突发大量请求，所有流量都压向同一台后端。
- 仅在必须保持会话粘性且无法共享 session（如老旧系统）时使用；
- 若用 Redis 或 JWT 做无状态 session，应优先关闭 ip_hash，改用轮询或 least_conn；
- 注意：NAT 环境下多个用户共用一个出口 IP，会导致严重倾斜。
