least_time是Nginx Plus等支持的动态负载均衡算法，基于滑动窗口内平均响应时间、健康状态和连接数综合选节点，需配合health_check与keepalive使用。
通过 least_time 配置实现基于最快响应时间的集群动态分流，核心是让负载均衡器持续观测后端节点的实际响应延迟，并将新请求优先转发给近期响应最快的节点。这不同于静态权重或简单轮询，属于自适应、实时性较强的动态调度策略。
理解 least_time 的工作原理
least_time 是 Nginx Plus（商业版）和部分增强型开源代理（如 Tengine、OpenResty 配合 Lua 模块）支持的上游调度算法。它不是仅看单次响应，而是基于滑动窗口内多个请求的平均响应时间（或最小/加权值），并结合健康状态、连接数等因子综合打分。Nginx 开源版原生不支持该指令，需确认所用版本或替代方案。
关键点包括：
- 依赖
upstream块中启用least_time指令，并指定响应时间度量方式（如header、last_byte或connect） - 通常需配合
keepalive和health_check使用，确保连接复用与节点可用性感知 - 响应时间数据来自真实流量反馈，无需人工预设权重，适合响应波动大的微服务集群
配置示例（以 Nginx Plus 为例）
以下为典型 least_time 配置片段：
upstream backend {
least_time header; # 以 HTTP 响应头发送完成时间为基准
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
<pre class="brush:php;toolbar:false;">keepalive 32;
health_check interval=5 fails=3 passes=2;}
说明：
-
least_time header表示使用从后端收到响应头的时间点计算延迟；也可用last_byte（整个响应体接收完成）或connect（TCP 连接建立耗时） - 健康检查确保只对存活节点统计响应时间，避免将故障节点纳入比较
- 建议开启
keepalive减少连接开销，使响应时间测量更贴近真实服务处理耗时
开源环境下的等效实践
若使用 Nginx 开源版，可通过 OpenResty + Lua 实现类似逻辑：
- 利用
lua_shared_dict存储各 upstream server 的近期响应时间滑动平均值 - 在
log_by_lua*阶段记录每个请求的sent_http_x-response-time或ngx.now() - ngx.var.time_iso8601差值 - 在
balancer_by_lua*中读取字典数据，按最小平均延迟选择目标节点 - 需自行实现超时剔除、衰减更新、并发安全等细节，复杂度高于原生命令
注意事项与调优建议
实际部署中需关注以下问题：
- 初始阶段无历史数据时，可能退化为轮询或随机，可配合预热请求或设置初始权重过渡
- 响应时间易受网络抖动影响，建议启用平滑算法（如指数加权移动平均 EWMA）而非简单算术平均
- 避免“羊群效应”：多个客户端同时倾向同一最快节点，可引入轻微随机扰动或设置最大连接数上限
- 日志中开启
$upstream_connect_time、$upstream_header_time、$upstream_response_time便于监控与验证策略生效
