Varnish缓存服务器是工作在代理模式的。意思是说,由varnish接收用户的请求,把用户请求资源的URL做“哈唏”编码后,做为“键”与缓存条目中的键做比对:
1、如果,缓存条目有一模一样的键的话,那么该键对应的值就是用户请求URL对应的资源,
varnish把该键对应的值取出来,响应给客户端。
2、如果,缓存条目没有与之匹配的键的话,那么varnish 就向后端服务器(backup server)发送请求。当后端服务器(backup server )构建完响应报文响应varnish,varnish服务器收到后端服务器(backup server)的响应后,会把:用户请求的URL做“哈唏”编码后,作为键(key),该URL对应的资源作为值(value),保存在varnish的缓存中。
这就是所谓的,插入缓存条目。 varnish的缓存条目是:key:value 方式存在的。
然后,varnish再构建响应报文响应客户端。
这就是,varnish 缓存服务器的正常工作流程。
如下图所示:
缓存服务器Varnish概念篇
CentOS 5.8下Varnish-2.1.5的安装配置
RedHat脚本改用CentOS源更新安装Nginx、PHP 5.3、Varnish
那么如何实现varnish缓存的管理呢?
1、varnish接收用户请求后,是如何根据用户请求的报文来决定是否查找缓存的呢?
由上图所知。当 varnish 服务器接收到用户请求后,分析用户请求的 URL 是否符合缓存标准,再查找缓存。这样是为了避免花费在与缓存条目比对的时间。如果,缓存条目较多的话,做缓存比对也是需要很长时间的。varnish通过如下方式,控制那些URL可以查找缓存的:
varnish 在vcl_recv状态引擎定义策略,怎么样处理用户的请求的。如:varnish 处理的客户端请求的标准、如果判断是否查找缓存的。
sub vcl_recv {
# varnish 在vcl_recv状态引擎定义的策略来控制,varnish服务器只处理指定http协议请求资源的方法,的URL
if (req.request != "GET" &&
req.request != "HEAD" &&
req.request != "PUT" &&
req.request != "POST" &&
req.request != "TRACE" &&\
req.request != "OPTIONS" &&
req.request != "DELETE") {
/* Non-RFC2616 or CONNECT which is weird. */
return (pipe); -----> 用户请求的访问的服务虽然是:tcp/80 但是,varnish不处理除了,GET、HEAD、PUT、POST、TRACE、OPTIONS、DELETE请求资源的方法。直接让该请求把该请求交给backup server.
}
# 再使用下述策略来过滤用户请求资源时所使用的方法;判断用户请求资源时使用的方法不是:GET、HEAD 就绕过查找缓存的操作
if (req.request != "GET" && req.request != "HEAD") {
/* We only deal with GET and HEAD by default */
return (pass); -----> 绕过查找缓存操作,varnish直接向 backup server 请求资源
}
# 使用vcl_recv状态引擎判断用户的请求,都不符合上述:if 条件。那么该用户请求资源所使用的方法一定是:GET或HEAD。但是如果用户访问的是资源,需要通过口令认证
# 才可以访问的。用户请求该资源使用的也是"GET"方法。该用户请求的URL是不需要查找缓存的。
if (req.http.Authorization || req.http.Cookie) {
/* Not cacheable by default */
return (pass); -----> 绕过查找缓存操作,varnish直接向 backup server 请求资源
}
return (lookup); ------> 查找缓存
}
说明:
varnish 有很多内置变量保存了,http协议报文的信息。通过使用if判断这些信息,来控制varnish是如何使用缓存的。
如:
req.url ------> 记录用户请求的URL
req.request -------> 记录了用户请求资源使用的方法