我目前正在用Apache mod_load_balancer和mod_proxy调查负载平衡。 以后我也会看看其他负载平衡器，但有一点已经变得清晰了。 为什么几乎没有任何负载平衡器（如果有的话）根据工人机器的实际负载作出分配决定。
例如，Apache根据请求的数量，数据吞吐量和请求队列的长度来分配请求。 为什么他们没有一些机制将请求分发给CPU或内存使用率最低的机器？
我正在构build一个系统，每个请求都需要大量的CPU，以至于在我最大化所有CPU之前，2或3个工作机器只能服务10或20个并发客户机。 一些XML的请求是非常轻量级的，而其他的东西真的很重。
这是否真的在事物的计划上有所作为？ 有人发现，即使是一个基于CPU的分配algorithm，最终也可以归结为循环方式。 它是否增加额外的开销，使得它不值得。
有没有其他的负载平衡器提供这种设施，他们提供它，没有人因为什么原因使用它。
这似乎是一个很好的东西，但似乎没有人执行它。 我很困惑，需要一些关于这个问题的build议。
基于资源的负载平衡的一个主要问题是负载信息在您做出路由决策时变得陈旧。 有一个关于过时的话题的学术论文，你可能想要读取的是解释状态负荷信息 。 你可以得到令人讨厌的副作用，比如发送太多的负载到一个似乎没有得到充分利用的盒子，然后压倒它。 简而言之，基于负载的平衡似乎是首先向所有人开放的最好方式，但事实certificate简单的方法往往在实践中更好地工作。
在大多数负载平衡中，简单的algorithm通常都是很好的，因为交易是短暂的，或者它们导致如此低的负载，以至于循环或者随机分布将足够接近以达到良好的平衡。 通常需要开销以吸收来自发生故障的服务器的负载（如果您closures所有3的最大利用率，一旦死亡负载将级联，并且会丢失整个集群）。
一个解决办法可能是创build两个队列，一个是“重物”，一个是“轻物”。 我会称之为“轻量级” 负载均衡和“繁重” 作业调度 – 换句话说，他们看起来像是不同的问题。 然后，对每个客户端的最大会话数量以及作业调度的通用队列进行限制。 虽然我不知道一个理想的工具。
一般来说，我发现“加载”是一个非常具体的术语，它是从大量不同的应用程序派生而来的。 由于没有前端负载平衡器可以知道这个细节（开箱即用），并且有一些经过仔细调整的连接限制的循环法基本上起作用，所以并不总是值得痛苦的。
在我开发内部应用程序的环境中，尝试将“监视器”页面作为负载平衡器用于监视节点状态（即上/下）的应用程序的一部分。 这可以被扩展为包含负载平衡器可以用来调整对该节点的负载的整数负载因子。 我们所定义的是一致的接口，这个整数值将导致负载均衡器做什么。 然后，这取决于应用程序和大量的负载testing，以确保应用程序没有做太多时髦来加载分配。
继Kyle Brandt提到的工作队列之后，负载平衡的另一种方法是工作人员从队列中提取请求，而不是标准负载平衡器向工作人员推送请求（或根据具体情况挤入） 。 Mongrel2 Web服务器（ http://mongrel2.org/ ）就是这种设置的一个例子，它使用0MQ（ http://www.zeromq.org/ ）作为应用程序工作者的分配机制。 由于繁重的处理，机器会变慢，因此不会从队列中检索新的请求。 您仍然可能会遇到很多重复的请求，但这个问题很快就会被工作人员短路。 把工作分成“打字”的队列是相当简单的，正如Kyle所build议的那样。 对于后端应用程序来说，这是一个相当大的变化，以支持0MQ请求的拉取，但如果从头开始，那么这可能是一个前进的方向。