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 次，平衡及时性与稳定性
