那里有什么样的负载平衡algorithm

对于HTTP负载平衡器最常见的负载平衡algorithm是恕我直言：

• 循环 （有时称为“下一个循环”）。

• 加权循环 – 作为循环赛，但一些服务器获得更大的整体stream量份额。

• 随机 。

• 源IP哈希。 根据源IP地址将连接分配给后端服务器。 如果networking节点失败并被停止使用，分发将发生变化。 只要所有的服务器都在运行一个给定的客户端IP地址就会一直到同一个Web服务器。

• url哈希。 与源IP散列非常相似，散列除了在请求的URL上完成之外。 在代理caching之前进行负载均衡时非常有用，因为对给定对象的请求将始终只转到一个后端caching。 这避免了caching重复，将相同的对象存储在多个/所有caching中，并增加了后端caching的有效容量。

• 最less的连接 ，权重最小的连接。 负载均衡器监视每个服务器的打开连接数，并发送到最不繁忙的服务器。

• 最less的stream量 ，最小的stream量。 负载平衡器监视每个服务器的比特率，并发送到传出stream量最less的服务器。

• 最小的延迟 。 Perlbal向后端服务器发出一个快速的HTTP OPTIONS请求，并将请求发送给第一台服务器来回答。

可以说，上述不是严格的计算机科学意义上的algorithm，它们是对常见方法的更一般的描述。 以下是思科的一篇小文，介绍了他们使用的一些algorithm 。 来自其他供应商的实施将略有不同。

在边缘情况下，更奇特的algorithm是有用的 – 例如videostream可能适用于“最小stream量”。 但总的来说，对于大多数Web应用程序和网站来说，最佳解决scheme是：

• 一个共享/分布式会话系统 ，以便任何webnode都可以回答任何用户请求（即会话cookie等用户会话数据同样适用于所有服务器）。

• 使用循环 （可选加权循环） 或随机分布进行负载平衡。 循环和随机是简单而有弹性的algorithm，没有任何“热点”问题，即后端的负载分配在所有情况下都保持公平。

这个问题是不完整的：

负载平衡什么？

CPU可能会饱和; 通常的观点是向后推动资源而不是拉动资源。

磁盘有多种不同的负载来平衡，如空间，读取速度，写入速度，吞吐量等。

networking可以基于延迟或总吞吐量进行负载平衡…

人们可以基于个人能力进行负载均衡; 一些多任务很好，另一些则没有，然后是质量与数量。 您可能会根据多种因素优化您的人力资源，并为不同的属性赋予不同的权重。

以上内容远非详尽无遗， 重点是不同的资源采用完全不同的负载均衡types。 在他们可用的属性和能力中，你必须说明哪些是有利于平衡的。

你想要平衡的是制定一个好的平衡algorithm的第一个标准。 而只有三个的build议是…没有启示。 值得博士做一个适当的工作，试图描绘“负载均衡”的所有方法。

RT

不是你的问题的直接答案，而是我们发现有用的实际解决scheme。 使用LVS和脉冲守护进程，我们的HTTP负载平衡configuration为调用一个自定义的bash脚本，通过简单的SSH连接和正常运行时间调用来确定“真实服务器”上的负载。

然后，根据服务器的平均负载，每个服务器设置一个权重。 不是最科学的方法，因为平均负载不一定表示由这些连接引起的HTTP连接或CPU负载。 尽pipe如此，我们已经取得了惊人的成效。

我的2c。 因人而异。

PS：看看LVS项目 – 你一定会发现有关负载平衡调度实现的信息。