Lin Asked: 2009-08-08 15:23:32 +0800 CST2009-08-08 15:23:32 +0800 CST 2009-08-08 15:23:32 +0800 CST 需要 HAproxy + Varnish + nginx 设置建议 772 目前，我有两个运行 HAProxy 的负载均衡器，它们将请求转发到后端，每个后端都在 nginx 前面运行 Varnish 缓存。我认为这会在后端服务器上分配大部分带宽，但我的负载平衡器似乎每月使用数百 GB 的带宽，这与后端使用的带宽很接近。我想这是有道理的，因为流量都是通过负载平衡器路由的？ 我的负载均衡器和后端位于美国的不同地区。如果我只在前端运行 HAProxy 和 Varnish，而在后端只运行 nginx，效率会更高吗？谢谢！ nginx 2 个回答 Voted womble 2009-08-08T22:31:46+08:002009-08-08T22:31:46+08:00 你把它弄反了……把 Varnish 放在负载均衡器前面，这样他们就可以尽早回答尽可能多的请求（如果你有太多的流量需要一个 Varnish 来处理，那么用像 ldirectord 这样的低开销 TCP 负载均衡器）然后让 Varnish 传回 HAProxy 实例并从那里开始。在 HAProxies后面使用Varnish对我来说似乎完全倒退了——你想尽可能早地减少流量。 Best Answer user2874 2009-08-11T12:54:24+08:002009-08-11T12:54:24+08:00 对于您的第一个问题：是的，在正常的 HAProxy 配置中，所有流量都流经负载均衡器，无论是当它进入您的服务器，还是从服务器再次流出到客户端时。对于所有负载平衡器，这或多或少总是如此，因为它们通常被实现为 HTTP 代理或 IP 级 NAT/路由框。例外是使用“直接服务器返回”(DSR) 时，请参阅此 inlab.com 对 DSR 的解释。 我的负载均衡器和后端位于美国的不同地区 诶，为什么？如果您使用的是地理负载平衡或多播路由，那么我不希望您会问这些问题。在正常用例中，您确实应该将服务器放在同一个机架上，并在快速无冲突、低延迟的 LAN 上。这将使您的服务器软件的生活更轻松，并为您的服务器提供更多性能，以及更一致/可靠的性能特征...... 您正在使用的软件的规范设置是这样的： nginx（用于 HTTP 压缩）--> Varnish 缓存（用于缓存）--> HTTP 级负载均衡器（HAProxy，或 nginx，或 Varnish 内置）--> webservers。 或者，如果您的负载很高，您可以在最前面有多个 nginx 或 varnish 服务器；但这适用于每秒有数千个请求的站点。 关于你的第二个问题当你问“更高效”时，我怀疑你的意思。更高效，因为服务器之间的流量更低？稍微地，因为 Varnish 缓存阻止了一些流量返回更远的地方。在 CPU 使用方面更高效——只要保持逻辑结构相同，您就可以将服务转移到负载较少的物理服务器上。
你把它弄反了……把 Varnish 放在负载均衡器前面，这样他们就可以尽早回答尽可能多的请求（如果你有太多的流量需要一个 Varnish 来处理，那么用像 ldirectord 这样的低开销 TCP 负载均衡器）然后让 Varnish 传回 HAProxy 实例并从那里开始。在 HAProxies后面使用Varnish对我来说似乎完全倒退了——你想尽可能早地减少流量。
对于您的第一个问题：是的，在正常的 HAProxy 配置中，所有流量都流经负载均衡器，无论是当它进入您的服务器，还是从服务器再次流出到客户端时。对于所有负载平衡器，这或多或少总是如此，因为它们通常被实现为 HTTP 代理或 IP 级 NAT/路由框。例外是使用“直接服务器返回”(DSR) 时，请参阅此 inlab.com 对 DSR 的解释。
诶，为什么？如果您使用的是地理负载平衡或多播路由，那么我不希望您会问这些问题。在正常用例中，您确实应该将服务器放在同一个机架上，并在快速无冲突、低延迟的 LAN 上。这将使您的服务器软件的生活更轻松，并为您的服务器提供更多性能，以及更一致/可靠的性能特征......
您正在使用的软件的规范设置是这样的：
nginx（用于 HTTP 压缩）--> Varnish 缓存（用于缓存）--> HTTP 级负载均衡器（HAProxy，或 nginx，或 Varnish 内置）--> webservers。
或者，如果您的负载很高，您可以在最前面有多个 nginx 或 varnish 服务器；但这适用于每秒有数千个请求的站点。
关于你的第二个问题当你问“更高效”时，我怀疑你的意思。更高效，因为服务器之间的流量更低？稍微地，因为 Varnish 缓存阻止了一些流量返回更远的地方。在 CPU 使用方面更高效——只要保持逻辑结构相同，您就可以将服务转移到负载较少的物理服务器上。