备用机（backup）仅在所有非backup服务器不可用时启用，不参与日常流量分发，不能用于分担瞬时流量高峰；真正应对高峰需结合轮询、主动健康检查、备用池、请求排队/限流。
轮询策略本身不主动分担瞬时流量高峰，备用机（backup）也不会参与日常流量分发——它只在所有非 backup 服务器全部不可用时才启用。所以“用 backup 分担高峰”是常见误解。真正应对瞬时流量高峰，需结合轮询 + 主动健康检查 + 备用池 + 请求排队/限流，而不是靠 backup 承载常规压力。
备用机的正确角色与配置方式
backup 是兜底机制，不是扩容手段：
- 标记为
backup的 server 不会出现在正常轮询序列中，哪怕其他节点负载已满 - 只有当 upstream 中所有非 backup 节点都因
max_fails被标记为不可用时，Nginx 才会把请求转给 backup 节点 - 典型配置示例：
upstream api_backend { server 192.168.1.10:8080 max_fails=3 fail_timeout=30s; server 192.168.1.11:8080 max_fails=3 fail_timeout=30s; server 192.168.1.12:8080 backup; # 仅故障时启用 }
真正缓解瞬时高峰的轮询增强组合
要在轮询基础上扛住突发流量，需叠加以下三层机制：
-
前置限流排队：用
limit_req在 Nginx 接入层缓冲请求，避免后端雪崩
例如每 IP 每秒 10 请求，允许最多 50 个排队：limit_req_zone $binary_remote_addr zone=burst_ip:10m rate=10r/s;<br>limit_req zone=burst_ip burst=50 nodelay;
-
扩大系统连接缓冲：调大
backlog防止 TCP 连接被内核丢弃
在listen指令中显式声明：listen 80 backlog=65535;，并同步调整系统参数net.core.somaxconn -
动态扩容备用池（非 backup）：把性能更强的机器加进主轮询池，并设更高权重
例如新增一台高配机器：server 192.168.1.100:8080 weight=5;，它会在轮询中自然承接更多请求
何时该考虑替代轮询算法
如果瞬时高峰伴随大量长连接（如 WebSocket、SSE）或请求处理时长差异极大，纯轮询容易导致某台后端积压严重。此时应切换更适配的策略：
- least_conn：新请求优先打到当前活跃连接最少的机器，对短时洪峰更友好
- 加权轮询 + 自动扩缩容联动：配合服务发现（如 Consul），动态增删带 weight 的 server 行，实现弹性调度
- 多 upstream + map 切流：按请求特征（如 URL、header）或系统指标（如 CPU 使用率）实时切到不同 upstream，其中可包含一组专用于高峰的 high-capacity 节点
验证是否真起作用的关键动作
光写配置没用，必须验证实际效果：
- 在 access_log 中记录
$upstream_addr，压测时看请求是否真的落到 backup 上（正常情况下不应出现） - 用
ss -lnt观察 listen 端口的 Recv-Q 值，确认 backlog 是否被有效利用 - 监控各后端的 5xx 错误率和响应延迟，若 backup 频繁被触发，说明主集群容量或健康检查阈值设置不合理
