为什么负载平衡器算法不允许根据当前 CPU 或内存使用情况选择工作机器

Question

我目前正在研究 Apache mod_load_balancer 和 mod_proxy 的负载平衡。稍后我还将查看其他负载平衡器，但有一件事已经很清楚了。为什么几乎没有任何负载均衡器（如果有的话）根据工作机器的实际负载做出分配决策。

例如，Apache 根据请求数量、数据吞吐量和请求队列长度来分配请求。为什么他们没有某种机制将请求分发到 CPU 或内存使用率最低的机器。

我正在构建一个系统，其中每个请求都需要大量CPU，以至于 2 或 3 台工作机器只能为 10 或 20 个并发客户端提供服务，然后我才能将它们的所有 CPU 都用完。一些对 xml 的请求非常轻量级，而另一些对“东西”的请求非常重。

它真的对事物的计划有什么影响吗？有没有人发现即使是基于 CPU 的分发算法最终也会变成循环模式。它是否会增加额外的开销，使其不值得。

是否有任何其他负载平衡器提供此功能，它们是否提供它并且没有人出于任何原因使用它。

这似乎是一件非常好的事情，但似乎没有人实施它。我很困惑，需要一些关于这个主题的建议。

Answer 1

基于资源的负载平衡的主要问题之一是负载信息在您做出路由决定时变得陈旧。您可能想阅读一篇关于过时主题的学术论文，名为Interpreting State Load Information。您可能会遇到令人讨厌的副作用，例如向一个似乎未充分利用的盒子发送过多负载，然后使其不堪重负。简而言之，对于每个人来说，基于负载的平衡一开始似乎是最好的方法，但事实证明，简单的方法在实践中往往效果更好。

在大多数负载平衡中，简单的算法通常都很好，因为事务要么是短暂的，要么是它们导致的负载很低，以至于循环或随机分布将足够接近良好的平衡。无论如何，通常都需要开销来吸收故障服务器的负载（如果您关闭了所有 3 个的最大利用率，一旦一个死机，负载就会级联，您将丢失整个集群）。

一种解决方案可能是创建两个队列，一个用于“重物”，一个用于“轻物”。我会称“轻量级”负载平衡和“重量级”作业调度——换句话说，它们看起来是不同的问题。然后只限制每个客户端的最大会话数，并为它们设置一个用于作业调度的通用队列。不过，我不知道有什么理想的工具可以解决这个问题。