nginx流量均衡需据后端状态、请求特征和业务需求选择策略：轮询适用于性能一致的无状态服务但不感知实时负载；least_conn适配长连接与响应不均场景；加权轮询按硬件能力分配流量；ip_hash与url_hash侧重会话一致性而非均匀性。
要让 Nginx 真正把流量“均匀分担”到后端集群，并不是选个策略就完事，而是得看后端实际状态、请求特征和业务需求来匹配。轮询看着公平，但服务器负载不均时反而会加剧不均衡；least_conn 在长连接或响应时间差异大时更靠谱；加权轮询则适合硬件能力明显不同的节点。
轮询策略：简单公平，但只适用于理想条件
这是 Nginx 默认行为，不写任何关键字就生效。它按顺序把请求发给每个后端，循环往复。优点是零配置、开销小、逻辑清晰。
- 适合所有后端性能一致、响应时间稳定、无状态服务（比如纯 REST API）
- 自动感知故障：通过 max_fails 和 fail_timeout 参数，连续失败几次后临时剔除节点，恢复后再加入
- 不感知实时负载——哪怕某台机器 CPU 已 95%，只要没超 fail 次数，照样继续收请求
least_conn：动态适配，更适合压测与长连接场景
这个策略优先把新请求交给当前活跃连接数最少的后端。它不依赖预设权重，而是根据运行时状态做决策，对不均响应、慢响应、WebSocket 等长连接服务特别友好。
- 配置只需在 upstream 块开头加一行：least_conn;
- 比轮询更能缓解“雪崩前兆”——避免某台机器因连接堆积率先拖垮
- 注意：Nginx 开源版支持该指令，但连接数统计是近似值（基于 worker 进程本地计数），非全局精确；高并发下仍足够有效
加权轮询：让强机多干活，弱机少扛压
当后端服务器 CPU、内存、磁盘 IO 明显不同，比如一台 16C32G，另一台 4C8G，硬用轮询会导致弱机早早满载。这时 weight 就是关键调节杠杆。
- 权重是相对比例，不是绝对数值。例如 weight=5 和 weight=1，意味着前者理论承接 5/6 的请求
- 建议结合压测结果调整：先用轮询跑一轮，观察各节点 CPU、RT、错误率，再按实际吞吐能力反推合理权重
- 不要设过高权重（如 weight=100），容易造成调度抖动；一般控制在 1–10 区间内更平滑
ip_hash 与 url_hash：不是为“均匀”，而是为“稳定”
这两类哈希策略本质是牺牲均匀性，换取一致性。它们会让特定用户或特定资源始终落在同一台后端，适用于有状态场景，但天然导致流量倾斜。
- ip_hash：按客户端 IP 哈希，解决 session 粘滞问题。但 NAT 环境下大量用户共用出口 IP，会造成单点过热
- hash $request_uri consistent：一致性哈希，适合缓存类服务（如 CDN 回源）。增减节点时，仅少量 key 重映射，缓存命中率更稳
- 二者都不推荐用于纯粹追求“均匀分担”的压测或无状态 API 场景
