我计划采用类似于以下的架构：
nginx - nginx - nginx - nginx
\ \ / /
varnish
/ | \
app server - app server - app server
（应用服务器都是“相同的”，因为请求可以通过 Varnish 路由到其中任何一个。）该图中的 Varnish 每秒将处理（可能）数十万个请求。它能做到吗？
出于故障转移和性能原因，我更愿意运行多个 Varnish 服务器，但我看到的直接问题是缓存没有多大用处，因为每个请求都会到达不同的 Varnish 服务器，直到每个 Varnish 服务器都有缓存对象的副本。正确的做法是什么？（再次说明，应用服务器与 Varnish 相同，请求路由到哪个服务器并不重要。我希望有多个 Varnish 服务器（在 nginx 的负载平衡后面）处理请求。）
答案1
我最近也遇到了同样的问题。Varnish 每秒可以处理相当多的请求，但你应该用你的设置（硬件、网络、响应大小、命中率）来测试它，以了解性能数字。除了性能之外，还有故障转移的问题需要开始平衡。
如果 URL 是您的缓存键，您可以在 nginx 中设置一种机制，根据 URL 选择特定的 varnish 实例（varnish_instance = hash(url) modulo nr_of_varnishes）。如果 varnish 在将 URL 转发到后端或进行缓存查找之前重写 URL，并且不同的 URL 被重写为相同的新 URL，那么此技巧无效。
在我的例子中，我无法根据负载均衡器的 URL 进行路由。我们使用 lvs-dr，根本不知道负载均衡器的 URL。
我曾经考虑过在 varnish 中设置这样的分发机制。可以将其他 varnish 配置为“后端”，计算哈希值并将请求路由到正确的 varnish。“正确的”varnish 执行后端调用并将其存储在缓存中。其他 varnish 也可以存储结果，但不必这样做。此设置会使您的 varnish 配置更加复杂，因此在选择这样的路径之前请仔细考虑。直接路由（lvs-dr 的一部分）使其更加复杂。
最后我选择了一个简单的解决方案：将请求分发到 2 个大型 Varnish 实例上，无需任何智能工具。结果经过两次计算和缓存，但 Varnish 配置尽可能简单。