least_conn不削峰不限流，仅按实时活跃连接数动态分发请求；它不感知后端延迟或CPU压力，仅统计Nginx与后端的keepalive连接，突发流量下初始请求可能仍集中打向同一节点。
直接压测 least_conn 的“削峰分流能力”容易误解——它本身不削峰，也不限流，只是在多个后端间按当前连接数做动态负载分发。它的“抗压表现”，本质是看高并发下是否真能避免某台后端被瞬间打爆，以及连接分配是否足够及时、均匀。
理解 least_conn 的真实行为边界
least_conn 在 Nginx 中的逻辑是：每次新请求到来时，从 upstream 组中选出当前活跃连接数（ngx_connection_t 级别）最少的后端；若多个后端连接数相同，则轮询（round-robin）选一个。注意：
- 它只统计 Nginx 与后端建立的 长连接数（即 keepalive 连接），不是后端应用的实际处理请求数或队列长度；
- 不感知后端响应延迟、CPU/内存压力或业务排队情况；
- 无连接数预测、无平滑衰减、无超时回退机制；
- 在突发流量下，若所有后端初始连接数均为 0，前几批请求仍可能集中打到同一台（取决于哈希/轮询初始顺序和调度竞争）。
设计有效压测的关键控制点
要验证它在极限下的分发合理性，需排除干扰、聚焦连接态分布：
-
禁用 upstream keepalive（或设极短 timeout），让每个请求都新建后端连接，使
least_conn能实时反映每台后端的瞬时连接压力； - 后端服务必须支持连接级限流（如用 sleep + 单线程模拟阻塞），否则连接数涨得慢，无法暴露调度滞后性；
-
压测客户端开启大量并发连接（如 wrk -c 5000 -d 60s），并确保请求路径不带缓存、不复用连接（如用
--no-keepalive）； -
监控维度必须包括：Nginx 每秒 upstream connect 数、各后端 real-time active connection count（可通过
stub_status或自定义 log_format 记录$upstream_addr和连接建立时间）。
对比实验才看得清效果
单独跑 least_conn 没意义，必须对照：
- round-robin：观察是否出现明显连接倾斜（比如 8 台后端中 1 台承载 40% 连接）；
- ip_hash：验证一致性哈希在突发流量下是否加剧热点（尤其当客户端 IP 集中）；
-
加权 least_conn（weight 非均等）：测试权重是否被正确纳入计算（公式为
current_connections / weight）； - 可选：在 upstream 中混入一台
down或max_fails=1 fail_timeout=1s的节点，观察故障转移时连接是否快速重分配。
典型问题与调优提示
压测中常见“失效”现象，往往不是算法问题，而是配置或环境偏差：
- 后端启用 HTTP/2 或 connection reuse，导致 Nginx 统计的“活跃连接”远少于实际负载 —— 改用 HTTP/1.1 +
Connection: close测试； - 系统级连接数限制（
net.core.somaxconn、fs.file-max、ulimit）未调高，造成 Nginx 无法建连，掩盖调度逻辑； - 日志采样率过高或解析延迟，误判连接分布 —— 建议用
nginx -T核对配置，并用ss -tnp | grep :port | wc -l在后端直查 ESTAB 连接数； - 想“削峰”但仅靠
least_conn不够 —— 应叠加limit_req（漏桶）、limit_conn（连接数硬限）、或上游服务自身的熔断（如 Sentinel/Hystrix）。
不复杂但容易忽略：least_conn 是连接层的“轻量均衡器”，不是业务层的“智能调度器”。压测目标不是看它多聪明，而是看它在最朴素假设下（连接数 ≈ 负载）能否守住基本公平底线。
