你说的“后端”是什么意思？¶
考虑到我们正在接近Varnish 3.0，您可能认为我很久以前就已经确定了这个问题的答案，但一旦您尝试提高效率，事情就会变得非常迅速。
我们非常了解的Varnish的功能之一是能够同时加载多个VCL，并在它们之间即时无缝切换。
因此，假设您的VCL中有1000个后端，这不是一个不合理的数字，每个后端都配置了运行状况轮询。
现在，您可以稍微调整一下vclrecv{}并再次加载VCL，但是因为您不确定哪种方法是最好的，所以您需要加载两个VCL，这样您就可以无缝地来回切换。
为了无缝切换，每个后端的健康状态需要在我们切换到另一个VCL的瞬间保持最新。
这基本上意味着，要么所有VCL轮询其所有后端，要么它们必须以某种方式共享。
我们可以不考虑所有VCLS轮询所有后端的情况，因为它的伸缩性真的很糟糕，如果人们忘记vcl.丢弃他们尘土飞扬的旧VCL，就会用探测器打击后端。
没有代表就没有信息¶
由于运行状况将针对这些三元组中的每一个，因此我们需要找到一种在CLI和统计上下文中表示它们的方法。
只要我们把它们打印出来，这没什么大不了的，但如果您只是想要1000个后端中的一个的健康状态，您如何区分哪个后端呢？
这种语法纳粹的方式迫使人们每次都要输入：：
backend.health b1(127.0.0.1:8080,[::1]:8080)
这肯定不会受到只有一个后端的人的欢迎。
我认为，但在我实施之前，我不会承诺解决方案是一个类似通配符的方案，其中您可以编写如下内容：
b1 # The one and only backend b1 or error
b1() # All backends named b1
b1(127.0.0.1) # All b1s on IPv4 lookback
b1(:8080) # All b1s on port 8080, (IPv4 or IPv6)
b1(192.168.60.1,192.168.60.2) # All b1s on one of those addresses.
(非常欢迎投稿)
最后一个问题是，我们是否使用快捷方式表示 华而不实 ，答案是否定的，因为我们不想让统计信息计数器更改名称，因为我们加载了另一个VCL，并且突然需要禁用。
实施¶
轮询策略可以通过为vcl.use执行上的所有后端更新指向轮询规范的反向指针来实现。
在vcl.disard上，如果此VCL是活动轮询器，则它需要遍历VCL列表并替换另一个。如果列表为空，则后端无论如何都会停用。
我们应该在每个后端上驻留一个线程，或者让一个轮询器线程在后端需要轮询时将作业抛入工作池。
模式匹配仅限于CLI和可能的libvarnishapi
我想这会奏效的，
直到下一次，
保尔-亨宁，2010-08-09