我们正在运行一个安装程序,其中Varnish将后端请求缓存到多个后端实例。这是使用Director VMOD处理的。在后端服务器上完成新代码的新部署后,它们将脱机几秒钟(可能一分钟),但这是一个交错部署,因此首先将代码部署到一个实例上,然后将该实例重新联机,到下一个,等等。
在部署实例时,它将关闭其Web服务器,以确保在部署期间不会处理任何请求。为了解决这个问题,Varnish VCL内置了一个重启循环:
sub vcl_deliver {
# Restart specifically to catch timeouts on deploy
if (resp.status >= 500) {
# Restart goes to vcl_req and the director should choose another backend from the pool
return(restart);
}
强制重新启动将导致Director VMOD抢占一个未部署的下一个实例(因为只有一个同时部署)并得到有效答案。效果很好。
但是,当后端获取导致FetchError HTC status -1
(由于网络服务器关闭midrequest导致输入的意外结束)时,将调用vcl_backend_error子例程。发生这种情况时,将按预期触发重新启动,但Varnish不会转到vcl_backend_fetch,而是将生成的响应明显地缓存在VCL_backend_error中,并返回该响应。在原始响应和重新启动的响应的相关部分下面:
VCL_call RECV
- VCL_return hash
- ReqUnset Accept-Encoding: gzip, deflate
- ReqHeader Accept-Encoding: gzip
- VCL_call HASH
- VCL_return lookup
- VCL_call MISS
- VCL_return fetch
- Link bereq 101974384 fetch
- Timestamp Fetch: 1545038546.336891 8.103600 8.103600
- RespProtocol HTTP/1.1
- RespStatus 503
- RespReason Backend fetch failed
- RespHeader Date: Mon, 17 Dec 2018 09:22:26 GMT
- RespHeader Server: Varnish
- RespHeader Content-Type: text/html; charset=utf-8
- RespHeader Retry-After: 5
- RespHeader X-Varnish: 101974383
- RespHeader Age: 0
- RespHeader Via: 1.1 varnish (Varnish/5.0)
- VCL_call DELIVER
- VCL_return restart
- Timestamp Process: 1545038546.336900 8.103608 0.000008
- Timestamp Restart: 1545038546.336902 8.103611 0.000003
- Link req 101974385 restart
- End
VCL_call RECV
- VCL_return hash
- VCL_call HASH
- VCL_return lookup
- Hit 101974384
- VCL_call HIT
- VCL_return deliver
- RespProtocol HTTP/1.1
- RespStatus 503
- RespReason Backend fetch failed
- RespHeader Date: Mon, 17 Dec 2018 09:22:26 GMT
- RespHeader Server: Varnish
- RespHeader Content-Type: text/html; charset=utf-8
- RespHeader Retry-After: 5
- RespHeader X-Varnish: 101974385 101974384
- RespHeader Age: 0
- RespHeader Via: 1.1 varnish (Varnish/5.0)
- VCL_call DELIVER
- VCL_return restart
- Timestamp Process: 1545038546.336929 8.103637 0.000027
- Timestamp Restart: 1545038546.336932 8.103640 0.000003
- Link req 101974386 restart
- End
然后继续重新启动,从缓存中获取503错误,重新启动等,直到达到重新启动限制为止。
此行为是故意的吗?有谁知道为什么会这样以及如何预防呢?
答案 0 :(得分:1)
是的,这就是预期的行为。从文档中:
vcl_synth定义的对象永远不会存储在缓存中,这与vcl_backend_error定义的对象相反,后者可能会在缓存中结束。 vcl_synth和vcl_backend_error替换了Varnish 3中的vcl_error。
像往常一样,您可以避免在set beresp.uncacheable = true;
期间仅执行vcl_backend_error
。