一、什么是负载均衡调度算法¶

原笔记开头先强调了一个关键概念：
负载均衡不仅仅是“把请求转发出去”，还要决定请求到底分发给哪一台后端节点。

这种“如何分发”的方式，就是调度算法。

也就是说，在同一个 upstream 池里：

• 可能是轮流分
• 可能按权重分
• 也可能按客户端 IP 固定分

不同算法会直接影响：

• 请求分布是否均匀
• 节点压力是否合理
• 会话是否稳定

二、Nginx 中常见的几种调度算法¶

原笔记列出了几类高频算法：

这些算法并不是“谁高级谁就一定更好”，而是要看业务场景。

三、默认轮询 rr 适合什么场景¶

原笔记把 rr 作为最基础的算法来理解：

• rr 就是 Round Robin
• 也是 Nginx 默认的分发方式
• 请求会按顺序循环落到后端节点

它最适合的前提是：

• 后端机器配置接近
• 业务处理耗时差异不大

如果后端 Web 都差不多，默认轮询通常就足够用了。

四、为什么还会需要加权轮询 wrr¶

有时候后端节点并不完全一样，例如：

• 一台是 1C2G
• 一台是 2C8G

原笔记提到，这种场景下就可以使用权重，让性能更好的节点承接更多请求。
在 Nginx 里，这通常通过 server 后面的 weight 来体现。

也就是说：

• 权重大，拿到的请求更多
• 权重小，拿到的请求更少

这在灰度发布、测试节点参与集群、机器规格不一致时都很常见。

五、ip_hash 为什么常和会话保持一起出现¶

原笔记对 ip_hash 的总结很直白：

• 只要客户端 IP 一样
• 就尽量一直访问同一个后端节点

这会带来一个直接好处：

• 用户请求更容易和某台 Web 绑定
• 对一些依赖本地会话的应用，能缓解频繁掉登录的问题

所以原笔记把它和“会话保持/会话共享”联系在一起。

但同时它也有明显代价：

• 可能导致流量分布不均
• 某些 NAT 或代理场景下，大量用户可能共用同一个出口 IP

因此，ip_hash 能解决部分问题，但并不是所有会话问题的最佳答案。

六、least_conn 适合什么情况¶

原笔记把 least_conn 解释为“最小连接数”算法，也就是：

• 哪台机器当前连接数更少
• 新请求就更优先分给哪台

这类策略更适合：

• 单个请求处理时间差异较大
• 某些请求会长时间占住连接

相比简单轮询，它更关注“当前谁更闲”，而不只是“该轮到谁”。

原笔记还提到可以结合权重形成加权最小连接数，也就是 wlc 这一类思路。

七、哈希类算法通常用来做什么¶

原笔记还举了 url_hash 这类思路：

hash $request_uri;

这意味着：

• 相同的 URI 更可能被分到同一个后端节点

这类方式在静态资源缓存场景里很常见，因为它可以让相同资源更稳定地命中同一台缓存或同一类后端。

八、一个常见误区：算法不是越复杂越好¶

从原笔记的组织方式可以看出，学习这些算法的重点不是死记名字，而是先能回答两个问题：

1、我的后端节点是否同构
2、我的业务更需要均匀分发，还是更需要稳定落点

例如：

• 节点配置差不多：默认轮询就够
• 节点性能差异大：考虑加权轮询
• 需要弱会话保持：可以考虑 ip_hash
• 请求时长差异明显：可以考虑 least_conn

九、小结¶

负载均衡算法本质上是在回答“这个请求该给谁”。
原笔记这一节的核心价值就在于先建立选择算法的直觉：

• rr 适合普通均匀分发
• wrr 适合资源不均衡的集群
• ip_hash 适合让同一来源尽量命中同一节点
• least_conn 适合按当前负载更动态地调度

把这些基础概念搞清楚，后面再看健康检查、会话保持和真实集群案例就会顺很多。