这是很多问题！:-)
Q. Is this a safe approach?
表面上，我会这么说。
通常，在流量大且内容快速变化的新闻网站上设置 Varnish 可能是一项挑战。
一个非常好的检查方法是构建一个清漆盒，让它直接访问你的集群（而不是通过负载均衡器），并给它一个临时的公共 IP 地址。这将使您有机会针对 VCL 更改进行测试。您将能够测试评论、登录（如果有的话）以及其他任何事情，以确保没有意外。
Q. Will Google still track properly, including repeat visitors?
是的。cookie 仅在客户端使用。
您应该注意的一件事是，当后端发送 cookie 时，Varnish 也不会缓存内容。您将需要删除 vcl_fetch 上不需要的任何 cookie。如果 cookie 用于跟踪用户状态，这可能是一个问题。
Q. Is there anything else that I need to watch for in my policies for phase1?
您需要在 Rails 中禁用 rack-cache，并设置您自己的标头。请注意，如果您删除 varnish，Rails 将在没有缓存的情况下运行，并且可能会崩溃！
这就是我在 production.rb 中的内容：
# We do not use Rack::Cache but rely on Varnish instead
config.middleware.delete Rack::Cache
# varnish does not support etags or conditional gets
# to the backend (which is this app) so remove them too
config.middleware.delete Rack::ETag
config.middleware.delete Rack::ConditionalGet
在我的 application_controller 我有这个私有方法：
def set_public_cache_control(duration)
if current_user
response.headers["Cache-Control"] = "max-age=0, private, must-revalidate"
else
expires_in duration, :public => true
response.headers["Expires"] = CGI.rfc1123_date(Time.now + duration)
end
end
这是在我的其他控制器中调用的，因此我可以非常精细地控制对站点的各个部分应用多少 chacheing。我在作为 before_filter 运行的每个控制器中使用设置方法：
def setup
set_public_cache_control 10.minutes
end
（application_controller 有过滤器和空白设置方法，所以在其他控制器中可以是可选的）
如果您有部分网站不需要 cookie，您可以根据 VCL 中的 URL 将其剥离，并应用标头。
您可以像这样在 apache 配置中为静态资产设置缓存时间（假设您使用的是默认资产路径）：
<LocationMatch "^/assets/.*$">
Header unset ETag
FileETag None
# RFC says only cache for 1 year
ExpiresActive On
ExpiresDefault "access plus 1 year"
Header append Cache-Control "public"
</LocationMatch>
<LocationMatch "^/favicon\.(ico|png)$">
Header unset ETag
FileETag None
ExpiresActive On
ExpiresDefault "access plus 1 day"
Header append Cache-Control "public"
</LocationMatch>
<LocationMatch "^/robots.txt$">
Header unset ETag
FileETag None
ExpiresActive On
ExpiresDefault "access plus 1 hour"
Header append Cache-Control "public"
</LocationMatch>
这些标头将被发送到您的 CDN，这将使资产缓存更长时间。看着清漆，你仍然会看到请求的速度在下降。
我还会在页面不需要 cookie 但经常更改的所有内容上设置非常短的缓存。在我的例子中，我为主页设置了 10 秒的缓存时间。这对 Varnish 意味着每 10 秒会有一个用户请求发送到后端。
您还应该考虑将 varnish 设置为使用宽限模式。这允许它从缓存中提供稍微陈旧的内容，而不是将访问者暴露在后端对刚刚过期的项目的缓慢响应中。
Q. There are plenty of archived articles that don't get updated, is it safe to cache them forever?
为此，您需要更改您的应用程序，以便为那些已归档的文章发送不同的标题。这假设他们不会有 cookie。根据我在我的网站上所做的，我会这样做： -
在上面的设置中添加一个条件来更改缓存时间：
def setup
# check if it is old. This code could be anything
if news.last_updated_at < 1.months.ago
set_public_cache_control 1.year
else
set_public_cache_control 10.minutes
end
end
这会设置一个公共标头，因此 Varnish 将缓存它（如果没有 cookie），任何远程缓存（在 ISP 或公司网关处）也会如此。
这样做的问题是，如果您想删除故事或更新它（例如，出于法律原因）。
在这种情况下，您应该向 Varnish 发送一个私有标头来更改该 URL 的 TTL，但为其他所有人发送一个较短的公共标头。
这将允许您将 Varnish 设置为（例如）1 年的内容服务，同时它会发送标题以告诉客户每 10 分钟回来一次。
在这些情况下，您需要添加一个清除清漆的机制。
为了让你开始，我的 application_controller 中有第二种方法：
def set_private_cache_control(duration=5.seconds)
# logged in users never have cached content so no TTL allowed
if ! current_user
# This header MUST be a string or the app will crash
if duration
response.headers["X-Varnish-TTL"] = duration.to_s
end
end
end
在我的 vcl_fetch 我有这个：
call set_varnish_ttl_from_header;
vcl 函数是这样的：
sub set_varnish_ttl_from_header {
if (beresp.http.X-Varnish-TTL) {
C{
char *x_end = 0;
const char *x_hdr_val = VRT_GetHdr(sp, HDR_BERESP, "\016X-Varnish-TTL:"); /* "\016" is length of header plus colon in octal */
if (x_hdr_val) {
long x_cache_ttl = strtol(x_hdr_val, &x_end, 0);
if (ERANGE != errno && x_end != x_hdr_val && x_cache_ttl >= 0 && x_cache_ttl < INT_MAX) {
VRT_l_beresp_ttl(sp, (x_cache_ttl * 1));
}
}
}C
remove beresp.http.X-Varnish-TTL;
}
}
这样就不会将标头传递（s-max-age 会）传递给任何上游缓存。
设置方法如下所示：
def setup
# check if it is old. This code could be anything
if news.last_updated_at < 1.months.ago
set_public_cache_control 10.minutes
set_private_cache_control 1.year
else
set_public_cache_control 10.minutes
end
end
随时提出任何补充问题，我会更新这个答案！
