要实现节点恢复后的平滑流量预热,必须使用slow_start参数并满足四个条件:启用least_conn等支持动态权重的负载算法、配置健康检查机制、显式设置weight值、在server指令中完整声明slow_start。
要在节点恢复后实现平滑流量预热,核心是让 Nginx 在该节点被判定为“健康”时,逐步提升其承接流量的能力,而不是一上来就分发全量请求。这靠的是 slow_start 参数,但它不是独立生效的,必须满足几个硬性条件。
默认的 round-robin(轮询)不支持 slow_start,写了也无效。真正起作用的只有:
配置开头必须明确声明,例如:least_conn;,不能省略。
slow_start 不是“一加进去就启动”,而是等节点从 down → up 的状态跃迁时才触发。这就要求 Nginx 能识别“刚恢复”这个事件:
max_fails=2 fail_timeout=10s,连续失败后摘除,恢复后重新纳入并启动 slow_starthealth_check 指向 /actuator/health 等真实业务就绪端点,比只通端口更可靠没有健康检查,Nginx 就不知道节点何时“恢复”,slow_start 形同虚设。
slow_start 是在 weight 基础上做线性爬升,不是凭空生成权重。即使想用默认值,也得写出来:
server 10.0.1.20:8080 weight=5 slow_start=60s;
server 10.0.1.20:8080 slow_start=60s;(缺少 weight)时间单位支持 s 和 ms,比如 slow_start=300ms 适合极短预热场景;建议控制在 30–300 秒之间,过短没缓冲效果,过长影响扩容效率。
没有图形界面,但可以靠日志和接口观察:
log_format 中加入 $upstream_addr 和 $time_iso8601,按秒统计新恢复节点的请求数,应呈近似线性增长nginx-module-vts 的,可访问 /status 查看各节点实时连接与请求分布nginx -s reload 不会重置正在运行的 slow_start 计时器,但 nginx -s stop & start(即重启)会重新开始计时