如何在N个Apache服务器之间平衡传入的networkingstream量？

几乎任何“反向代理”都会按照你的要求去做。

例如Varnish，Pound和HAProxy都擅长他们所做的事情，但他们也有分歧 – 然而，对于你所要求的，他们中的任何一个都会做。 就我个人而言，我认为你最好用HAProxy，但这只是一个猜测。

您可能最好阅读有关负载均衡器的文章，以帮助您确定需要什么types的内容： http : //1wt.eu/articles/2006_lb/

另外，您可能会考虑使用预构build的服务，例如在Amazon的Elastic Compute Cloud上运行您的软件并使用Elastic Load Balancing。

首先，有一个重要的问题需要回答：
你是否需要用户会话由负载均衡器来处理，并且总是被驱动到同一个Web服务器（如果存在的话）？

• 会话不需要 ：在这种情况下，您应该使用高效的nginx程序作为负载均衡器。 这个configuration很容易设置，你基本上只需要在upstream upstream_name { server1, ..., serverN }语句中指定Web服务器的列表，那么对于一个给定的域，你需要一个简单的proxy_pass upstream_name指令。
  请参阅Nginx wiki 。

• 会话需要有一个类似的设置为磅表示cookie的名称将主持会话ID（ ID MYCOOKIENAME ），然后为所有服务器的BACKEND列表。
  请参阅磅设置例子 。

当出现对多个负载平衡器的需求时，您可能需要进行heartbeatconfiguration，以确保只有一个平衡器为给定域安装虚拟IP（如果需要会话，或者同时安装并向DNS提供两个IP地址例如）。 也许这应该在另一个问题的时候详细说明（随着工具的快速发展）。
另请参阅此链接 。

您应该需要一个非常好的理由来为您的架构引入额外的复杂性和单点故障。

循环负载平衡

• 不收费
• 很容易实现和pipe理
• 在客户端实现故障转移 – 唯一可以可靠检测故障的地方
• 隐式支持服务器亲和性，但仍允许故障转移，而不会出现会话pipe理与粘滞会话相关联的问题
• 在群集节点上不需要额外的软件/硬件/configuration

令我惊讶的是关于循环法的错误信息量。 如果我是一个愤世嫉俗的人，我可能会怀疑是否与生产昂贵的负载均衡硬件的供应商有任何联系。

我会承认的唯一的一点是

1. IPV4地址正变得稀缺 ，因此价格昂贵 – 但仍然很多。 比说一个Cisco CSS便宜得多。

2. 互联网越来越多地运行在networking服务上，并不是所有的开发者都能根据规范实施DNS支持。 但是我曾经使用过的每一个浏览器都应该如此

开始你的任务： http ： //httpd.apache.org/docs/2.1/mod/mod_proxy_balancer.html和http://www.barneyb.com/barneyblog/2009/02/26/apache-httpds-mod_proxy_balancer/

对于平衡器，您可以在http://www.linuxvirtualserver.org/查看LVS，也许运行ldirectord和心跳来指导stream量并执行故障转移。

作为一个上游代理， Nginx是非常棒的，我已经在每天使用1M + unique的configuration中取得了巨大的成功

好的，这是问了一会儿，我迟到了。 不过，这里还有一些补充。

杰基，你已经钉了很多。 您的插图显示了如何在大多数小型和中型安装上处理负载平衡。

你应该阅读Willy Tarreau的负载均衡介绍 ，Nakedible链接到。 它仍然有效，这是一个很好的介绍。

你需要考虑这些如何适合你的需求：

• TCP / IP级负载均衡器（Linux Virtual Server等）。 每个连接开销最低，速度最快，不能“看”HTTP。
• HTTP级负载均衡器（HAProxy，nginx，Apache 2.2，Pound，Microsoft ARR等）。 更高的开销，可以看到HTTP，可以gzip HTTP，可以做SSL，可以做粘滞会话负载均衡。
• HTTP反向代理（Apache Traffic Server，Varnish，Squid）。 可以将可caching的对象（一些网页，CSS，js，图像）存储在RAM中，并将其转发到后续客户端，而不涉及后端Web服务器。 通常可以做一些L7 HTTP负载平衡器所做的相同的事情。

还有第二个平衡器，因为我相信在某个时候平衡器也需要帮助。

那么，当然。 但负载平衡很简单，而且通常单个负载平衡器可以快速运行 。 我把这篇文章链接到了networking上，这只是一个单一的现代服务器可以提供什么性能的例子。 在需要之前不要使用多个LB。 当你需要一个通用的方法是在最前面的IP级负载平衡器（或DNS Round Robin），转到HTTP级负载平衡器，去代理和webapp服务器。

帮助“平衡器”应该是什么以及如何设置它们的最佳实践。

麻烦的地方是会话状态处理，并在一定程度上失败状态的行为。 设置负载均衡器本身比较简单。

如果您只使用了2-4个后端Web应用程序服务器，则基于源IP地址的静态散列可以是可行的。 这就避免了Web应用程序服务器之间共享会话状态的需要。 每个webapp节点都会看到总stream量的1 / N，而在正常运行情况下，客户到服务器映射是静态的。 尽pipe如此，它不适合大型安装。

两种最好的负载均衡algorithm，就是说它们在高负载，甚至负载分配下都具有良好的行为， 是循环和真正的随机负载平衡。 这两个都要求您的Web应用程序在Web应用程序节点上具有全局会话状态。 这个怎么做取决于webapp技术栈; 但通常有标准的解决scheme可用于此。

如果静态哈希和共享会话状态都不适合您，那么select通常是“ 粘性会话 ”负载平衡和每服务器会话状态。 在大多数情况下，这工作正常，这是一个完全可行的select。

平衡器会看到每个apache实例上有多less个连接（通过内部IP或永久IP的一些configuration列表）并平均分配连接

是的，有些网站使用这个。 存在许多不同的负载平衡algorithm的名称很多。 如果你可以select循环或随机（或加权循环，随机加权），那么我build议你这样做，出于上述原因。

最后一点：不要忘记，许多供应商（F5，思科等高端，fx Coyote Point和Kemp Technologies以更合理的价格）提供了成熟的负载均衡设备 。