轮询负载均衡需配合健康检查、连接复用、超时控制与实时监控才能保障稳定低延迟；适用于配置相近、响应稳定的后端，但存在算力差异时需升级为加权轮询或least_conn等动态策略。
Nginx 的轮询（Round Robin）负载均衡本身不感知后端真实负载，它只按顺序分发请求，无法自动实现“系统均衡响应”。要让轮询真正支撑稳定、低延迟的服务表现，必须配合可观测性与基础增强机制，否则容易出现弱节点积压、强节点闲置的情况。
轮询不是万能的，但它是可信赖的起点
轮询策略适用于后端服务器硬件配置相近、应用响应时间波动小、无明显性能瓶颈的场景。它的价值在于简单、公平、无状态，且默认启用无需额外配置。但一旦后端存在算力差异或瞬时抖动，纯轮询就会导致响应时间拉长——比如一台 CPU 已达 95% 的服务器仍会照常接收新请求。
必须搭配健康检查与故障隔离
轮询默认只做连接层探测（TCP 握手成功即认为可用），这远远不够。应显式配置容错参数：
-
max_fails=3：连续失败 3 次才标记为不可用 -
fail_timeout=30s：在此时间内失败达上限后，该节点暂停调度 30 秒 - 可选
backup标记备用节点，避免全量故障
这样当某台服务短暂卡顿或超时时，Nginx 能快速跳过它，防止请求堆积拖慢整体平均响应。
连接复用和超时控制直接影响响应效率
每个请求新建 TCP 连接会增加毫秒级延迟，尤其在高并发下显著放大。需在 upstream 和 location 中协同配置：
- upstream 块中加
keepalive 32;（保持最多 32 个空闲长连接） - location 中设置
proxy_http_version 1.1;和proxy_set_header Connection '';（禁用 close，启用复用） - 设置合理超时：
proxy_connect_timeout 3s;、proxy_read_timeout 10s;，避免慢响应阻塞后续请求
监控才是轮询持续有效的前提
上线后必须观测各节点的：
- 实际请求数（是否接近理论均值）
- 平均响应时间（P95 是否明显偏离）
- CPU 与内存使用率（是否存在单点过载）
- 主动失败次数（
upstream_addr日志中记录的失败节点）
若发现某节点响应时间持续偏高但请求数未下降，说明轮询没“感知”到问题，此时应切换为加权轮询 + 健康检查组合，或引入 least_conn 等动态策略。
不复杂但容易忽略
