轮询负载方案本身不直接提升处理质量，但通过均匀分发请求为高处理质量提供稳定基础；需结合健康检查、故障自动剔除、精细化超时控制、日志可观测性及压测验证，并在特定场景下切换为ip_hash、加权轮询或least_conn等策略。
轮询负载方案本身不直接提升“处理质量”，但它通过请求的均匀分发，为高处理质量提供稳定基础。关键在于：轮询只是起点，真正实现高处理质量需结合健康检查、故障自动剔除、合理超时设置和日志可观测性。
轮询是默认策略，但必须配合容错机制
单纯写几行 server 就启用轮询，容易忽略后端异常。Nginx 默认轮询不会主动探测后端是否存活，一旦某台服务宕机，仍会尝试转发请求，造成超时或失败。
- 添加
max_fails=2 fail_timeout=30s，让 Nginx 在连续失败 2 次后，30 秒内不再向该节点发请求 - 配合
proxy_next_upstream error timeout http_500 http_502 http_503，当后端返回这些错误时，自动重试下一节点 - 避免使用
down手动标记——它需要人工干预，不符合高可用要求
轮询 + 连接与超时精细化控制
高处理质量依赖端到端链路可控。仅靠轮询无法避免慢响应拖垮整体性能。
-
proxy_connect_timeout 5s：建立连接超时，防止卡在 TCP 握手 -
proxy_send_timeout 10s：发送请求体超时，防大文件上传阻塞 -
proxy_read_timeout 15s：等待后端响应超时，避免长尾请求堆积 - 建议所有超时值小于后端应用自身的熔断阈值（如 Spring Boot 的
hystrix.timeout）
轮询效果可验证，不可凭空假设
轮询是否真正在“均匀分发”？不能只看配置，得看真实流量分布。
- 开启 Nginx access log 中的
$upstream_addr字段，记录每次请求实际转发到哪个后端 - 用
log_format定义结构化日志，配合 ELK 或 Grafana 分析各节点请求占比、响应时间 P95/P99 - 模拟压测（如 wrk 或 k6），观察三台服务器 CPU、内存、请求耗时是否趋近一致
- 若发现明显倾斜，先排查后端处理能力差异（如数据库连接池、JVM GC）、再考虑是否改用加权轮询
轮询不是万能解，要懂何时该换策略
当业务出现以下情况，纯轮询可能损害处理质量：
- 用户登录态依赖 session，且后端未做共享存储 → 改用
ip_hash或接入 Redis session 集中管理 - 后端服务器规格差异大（如 8C16G 和 2C4G 混部）→ 启用加权轮询，按资源比例设
weight - 长连接类服务（WebSocket、gRPC 流式接口）→ 轮询易导致连接频繁重建，应结合
least_conn或 sticky session - 突发流量下部分节点已满载，其余尚有余量 → 单靠轮询无法感知连接数，
least_conn更合适
