Nginx负载均衡算法按需触发而非每次事件都执行，仅在请求进入upstream阶段、无可用keepalive连接且需选择后端时调用peer.get()；其性能取决于算法复杂度，如round_robin为O(1)，least_conn为O(n)，可通过启用keepalive、优化hash变量、合理配置健康检查来降低开销。

在 Nginx 的事件循环中，负载均衡算法**不发生在每次事件触发时**，而是在**上游服务器连接建立前、且当前请求需要转发到 upstream 时才执行**。它的执行时机与性能影响紧密相关，关键在于“按需计算”和“结果缓存”两个设计原则。

负载均衡算法实际触发的三个条件

只有同时满足以下三点，Nginx 才会调用对应的负载均衡方法（如 least_conn、ip_hash、round_robin 等）：

• 请求已进入 upstream 处理阶段（即匹配了 proxy_pass 或类似指令）
• 当前 upstream 块未配置 keepalive 连接复用，或复用失败（如连接断开、超时、被标记为不可用）
• 需要为该请求选择一个后端 server —— 此时才会调用 peer.get() 回调，触发具体算法逻辑

常见算法的性能差异来源

不同算法对 CPU 和内存的消耗差异明显，主要取决于是否需要遍历、排序或维护状态：

• round_robin（默认）：仅维护一个整型计数器，O(1) 时间复杂度，几乎无开销
• least_conn：需遍历所有可用 peer，比较当前活跃连接数，O(n)，n 为可用后端数量；高并发下若后端多（如 >50），可能成为瓶颈
• ip_hash / hash $arg_uid：依赖哈希计算 + 查表，单次 O(1)，但哈希桶冲突或 key 分布不均可能导致个别后端过载
• random（with two choices）：随机选两个节点再比连接数，平均 O(1)，最坏 O(2)，比 least_conn 更轻量且更均衡

如何降低负载均衡环节的性能损耗

核心思路是减少“每次请求都重算”的频率：

• 启用 upstream keepalive（如 keepalive 32;），复用连接，避免重复选节点
• 对读多写少场景，考虑使用 hash 类算法 + 一致性哈希模块（如 nginx-sticky-module-ng），提升缓存命中率
• 避免在 hash 指令中使用复杂变量（如 $request_uri），防止每次解析开销增大
• 监控 nginx_stub_status 中的 Active connections 和 upstream 的 requests 分布，验证是否出现倾斜或频繁重选

注意：健康检查与负载均衡的协同关系

健康检查（health_check 或第三方模块）本身不参与选节点过程，但它会动态修改 upstream 中 peer 的可用状态。这意味着：

• 一次健康检查失败 → peer 被标记为 down → 后续负载均衡将跳过它，间接改变算法输入集
• 过于激进的健康检查（如间隔 100ms + 3 次失败即下线）会导致 peer 集频繁变化，使 least_conn 等算法反复重新评估，增加锁竞争（尤其在多 worker 下）
• 建议将健康检查间隔设为秒级（如 2s–5s），失败阈值设为 2–3 次，平衡及时性与稳定性