我目前正在研究使用 Apache mod_load_balancer 和 mod_proxy 进行负载平衡。稍后我还会研究其他负载平衡器，但有一点已经很清楚了。为什么几乎没有任何负载平衡器（如果有的话）根据工作机器的实际负载做出分配决策。
例如，Apache 根据请求数量、数据吞吐量和请求队列长度来分配请求。为什么他们没有某种机制将请求分配给 CPU 或内存使用率最低的机器呢？
我正在建立一个系统，每个请求都需要很多CPU 占用率高到 2 或 3 台工作机器只能为 10 或 20 个并发客户端提供服务，否则所有 CPU 都会被用尽。一些 xml 请求非常轻量，而其他“内容”请求则非常繁重。
这真的会对方案产生影响吗？有人会发现，即使是基于 CPU 的分配算法最终也会采用循环方式。这会增加额外的开销，使其不值得。
是否有其他负载均衡器提供此功能，他们是否提供此功能但无论出于何种原因无人使用它。
这看起来是一件非常好的事情，但似乎没有人实施它。我很困惑，需要一些关于这个问题的建议。
答案1
基于资源的负载平衡的主要问题之一是，当你做出路由决策时，负载信息已经过时了。有一篇关于陈旧你可能想读一下解释州负荷信息。您可能会遇到一些令人讨厌的副作用，例如向似乎未充分利用的盒子发送过多的负载，然后使其不堪重负。简而言之，基于负载的平衡最初对每个人来说似乎都是最好的方法，但事实证明，简单的方法在实践中往往效果更好。
在大多数负载平衡中，简单的算法通常都很好，因为事务要么寿命很短，要么导致负载很低，因此循环或随机分布足以接近良好的平衡。通常需要开销来吸收故障服务器的负载（如果您接近所有 3 个服务器的最大利用率，那么一旦其中一个服务器死亡，负载就会级联，您将失去整个集群）。
一个解决方案可能是创建两个队列，一个用于“重物”，一个用于“轻物”。我会把“轻物”称为负载均衡和“重头戏”作业调度- 换句话说，它们似乎是不同的问题。然后只需限制每个客户端的最大会话数，并为它们提供一个通用队列以进行作业调度。不过，我不知道有什么理想的工具可以解决这个问题。
答案2
一般来说，我发现“负载”是一个非常具体的术语，它来自大量因应用程序而异的指标。由于没有前端负载平衡器可以知道这个细节（开箱即用），而且循环调度和一些精心调整的连接限制基本上是有效的，所以它并不总是值得的。
在我工作的环境中，应用程序都是内部开发的，我尝试推动将“监控”页面作为应用程序的一部分，负载平衡器使用该页面来监控节点状态（即启动/关闭）。然后可以将其扩展为包含整数负载因子，负载平衡器可以使用该因子来调整该节点的负载。我们定义的只是一致的接口以及该整数值将导致负载平衡器执行的操作。然后由应用程序和大量负载测试来确保应用程序没有做任何对负载分配来说太奇怪的事情。
继 Kyle Brandt 提到的工作队列之后，负载平衡的替代方法之一是让工作程序从队列中拉取请求，而不是标准负载平衡器将请求推送给工作程序（或根据情况将其塞入）。此设置的一个例子是 Mongrel2 Web 服务器（http://mongrel2.org/）及其使用 0MQ（http://www.zeromq.org/) 作为应用程序工作者的分配机制。当机器由于繁重的处理而变慢时，它将不会从队列中检索新请求。您仍然会遇到大量“繁重”请求被同时检索的情况，但这个问题更容易被工作者自己解决。按照 Kyle 的建议，将工作划分为“类型化”队列是相当简单的。对于支持 0MQ 请求的后端应用程序来说，这是一个相当大的变化，但如果您从头开始，那么这可能是一种前进的方式。