轮询算法本身不直接提升响应稳定性，但通过均匀分发请求避免单点过载，使压力在多节点间自然摊薄；其稳定性依赖后端健康、能力相近，并需配合max_fails、fail_timeout、proxy_next_upstream等机制实现故障隔离与重试。
轮询算法本身不直接提升响应稳定性，但它通过均匀分发请求为稳定性打下基础——前提是后端服务器状态健康、能力相近。真正起作用的是它避免了单点过载，让压力在多个节点间自然摊薄。
轮询如何降低单点故障风险
默认轮询按顺序把请求依次交给每个后端，比如三台服务 A→B→C→A→B→C……这种固定节奏能防止某一台突然被大量请求压垮。即使某台响应稍慢，后续请求也会自动流到其他节点，不会像单点部署那样一卡全卡。
- 没有“热点服务器”，请求天然分散，CPU 和内存压力更平稳
- 配合 max_fails 和 fail_timeout 参数，Nginx 会自动踢出连续失败的节点，轮询队列动态收缩
- 只要至少一台后端存活，轮询仍能继续转发，服务不会完全中断
为什么单纯轮询不够稳定？关键短板在哪
轮询不看服务器实时负载、不查响应时间、也不管 CPU 是否已满。如果某台机器因 GC、磁盘 IO 或网络抖动变慢，轮询照样把下一个请求送过去，用户就可能遇到超时或错误。
- 它无法感知后端健康度变化，需要额外配置 health_check（商业版）或用 proxy_next_upstream 配合状态码兜底
- 无状态分发会导致会话丢失，登录态、购物车等场景需搭配 ip_hash 或外部 session 存储
- 当服务器性能差异大（比如一台是 16C32G，另一台是 4C8G），默认轮询会造成弱机更快过载
加权轮询：让轮询更贴合真实稳定性需求
给强机设高权重、弱机设低权重，相当于人为校准轮询节奏，使请求分配与处理能力匹配。这不是“锦上添花”，而是让轮询从“机械平均”走向“能力适配”。
- 例如：
server 192.168.1.10 weight=3;和server 192.168.1.11 weight=1;，前者约承担 75% 流量 - 权重不是绝对值，是比例关系；未声明 weight 的默认为 1
- 可结合 slow_start 参数，让新上线服务器逐步承接流量，避免冷启动冲击
轮询 + 基础防护 = 可用性底线
单独开个 upstream 用轮询，只是起点。要真正稳住响应，必须补上几项基础动作：
- 设置 proxy_connect_timeout、proxy_send_timeout、proxy_read_timeout，防止慢后端拖垮 Nginx
- 启用 proxy_next_upstream error timeout http_500 http_502 http_503 http_504，出错时自动重试另一台
- 限制单 IP 并发连接数（limit_conn）和请求频率（limit_req），防爬虫或误配置压垮后端
