阿里云-云小站(无限量代金券发放中)
【腾讯云】云服务器、云数据库、COS、CDN、短信等热卖云产品特惠抢购

Varnish基础概念详解

207次阅读
没有评论

共计 12734 个字符,预计需要花费 32 分钟才能阅读完成。

varnish 基础概念详解

比起 squid 更加轻量级,大致有以下几个特点:

·可以基于内存缓存,也可以在磁盘上缓存,但是就算存放在磁盘上,也不能实现持久缓存

    只要进程崩溃,此前缓存统统失效,无论是在内存还是在磁盘,但是现在已经具备持久缓存功能,但是仍然在实验阶段,经常容易崩溃,而且最大大小不能超过 1G

    如果期望内存大小超过几十个 G,比如图片服务器,纯粹使用内存,性能未必好,这时候可以使用磁盘进行缓存,或 SSD X 2 做 RAID 避免磁盘损坏,在实现随机访问上 ssd 硬盘要比机械硬盘要好的多,如果必须要缓存在磁盘上还是建议使用 ssd 磁盘 

·可以利用虚拟内存方式,IO 性能会非常好

   

·支持设置 0 -60 秒 精确缓存时间

 

·支持 VCL

    其配置是通过 vcl 编程语言来完成的

    其配置需要先转换成 C 代码,所以使用 vcl 所写的配置,要先转换成 C 语言代码,因此要依赖于 GCC 临时的编译 vcl 配置的,编译完之后才能运行起来

 

·独特的日志存储及管理机制

    日志既然保存在内存中,日志可以供多个应用程序所访问,所以一般查看命中率,当前请求有多少 get post 方法等等,都需使用专用的工具才可以查看,比如 varnishshtopvarnishlog 等命令工具用来查看日志信息

 

·支持使用 varnish 状态引擎

    通过巧妙的状态引擎的设计完成不同的引擎对用户的请求和缓存代理机制进行处理,用配置文件为状态引擎提供状态法则,完成缓存处理、完成代理处理等等

 

·堆文件(缓存文件管理机制)非常独特,使用的二叉树来实现缓存对象管理,因此可以达到积极删除缓存管理

缓存服务器 Varnish 概念篇 http://www.linuxidc.com/Linux/2014-05/101389.htm

缓存服务器 Varnish 概念篇 http://www.linuxidc.com/Linux/2014-05/101389.htm

Varnish Cache 的架构笔记 http://www.linuxidc.com/Linux/2013-10/91016.htm

CentOS 5.8 下 Varnish-2.1.5 的安装配置 http://www.linuxidc.com/Linux/2013-09/89916.htm

RedHat 脚本改用 CentOS 源更新安装 Nginx、PHP 5.3、Varnish http://www.linuxidc.com/Linux/2012-07/65801.htm

利用 Varnish 构建 Cache 服务器笔记 http://www.linuxidc.com/Linux/2012-07/65234.htm

缓存服务 Varnish 安装配置 http://www.linuxidc.com/Linux/2012-07/65228.htm

Varnish 编译安装所需准备 http://www.linuxidc.com/Linux/2012-07/65230.htm

Linux 下 Varnish 缓存的配置优化 http://www.linuxidc.com/Linux/2012-03/56435.htm

 

varnish 工作机制

Varnish 基础概念详解 

varnish 启动后会生成主控进程 Management, 可以理解为 nginx 的 master 进程

它并不负责真正代理并构建响应的而是由各子进程 child/cache 来完成的

 

主进程主要负责:

提供了以下接口:

CLI interface 

Telnet Interface 

Web Interface

 

因此我们通常都是用 CLI 接口

通过此接口可以与进程进行实时的交互

 

 

而主控进程通常负责以下操作:

·通过命令行接口与命令行的控制指令进行交互

·管理各个子进程,确保每个子进程都能正常工作,如果某个子进程挂掉,则自动让其启动起来

·完成整个 varnish 的初始化,能够完成基于 vcl 的编译器去编译 VCL 的配置文件,并且检测 vcl 配置文件是否存在语法错误的,如果有语法错误则拒绝编译,因此对于配置文件的分析和启用是由主进程所去实现的,这样能够避免子进程加载错误配置从而导致缓存崩溃

 

编译好之后生成共享模块,可以供需要这些模块的子进程所使用

 

子进程主要负责内容有:

·子进程需要生成日志的,因为用户的请求以及自身构建的响应都是由子进程负责的,所以需要生成日志,日志是需要存放在指定日志文件中,日志文件实际是一段共享内存区域

这些内存共享区域需要一些专门观测的工具来观测服务器的工作状态的

 

·使用命令行接口与 CLI 命令行进行交互

·用来实现将可以缓存的数据缓存下来,并且构建数据 hash 表

·生成日志和状态

·接收用户的请求并构建响应

·与各后端 cache 进行响应

·woker threads 真正意义上接收用户请求并构建响应的内部的工作线程

·缓存失效功能管理

 

因此 varnish 也是 master/slave 的架构

对 varnish 而言,在命令行接口里,可以极大的控制子进程的特性的,比如线程池最大可以启动多少个工作线程等

所以工作线程数 x 每个线程池的数 = 能够接收多少用户请求数

所以这些都是可以设定的,这些设定完成可以命令行接口进行交互设定

 

vcl 的配置主要跟子进程内部的状态引擎有关系,也就是说子进程的工作方式如下:

 

当一个用户的请求到达之后,要解码整个用户的请求(查看请求的方式是 get 还是 post 等 )

如果是 GET 方法,这里肯定有缓存,因此是否需要先查缓存,都是需要对其控制的

如果缓存命中或未命中,如果命中则在缓存中取,如果未命中则直接去上游服务器取数据,取得数据是否缓存,那都取决于缓存机制

如果上游服务器告知可以缓存则缓存在本地,如果告知不可缓存则不缓存,比如跟 cookie 或日志相关的数据肯定不能缓存

所以这些机制都需要做监测的

 

例:

    上游服务器缓存的是图片,但是图片中加了 cookie,图片一般而言跟用户的关联不是很大,除非是邮件服务器,虽然图片的关联不大,但是加了 cookie,就没办法在多个用户之间共享缓存,那这种情况下需要将 cookie 删掉,将图片缓存,并且缓存很长时间

所以这些处理机制都需要在内部完成策略的,所以这些都需要在不同的步骤完成

所以所谓的状态引擎就是当一个用户的请求到达后,大致走到哪一层,我们在哪个步骤哪个位置大致做出哪些处理,这就为状态

在请求的报文在大致经过的位置,内置了几个状态引擎,在用户的请求到达状态引擎的时候,我们在其状态引擎上做规则并做出相应处理

 

状态引擎图解

Varnish 基础概念详解

 

椭圆形为状态引擎

菱形的为条件判断

每个颜色箭头下面的字符串为处理机制

 

首先用户请求到达后,首先进入 vcl_recv

vcl_recv 对其做判断,是否命中缓存 (vcl_hash)

如果不想使用缓存则直接交由 vcl_pipe, 建立管道并交由后端服务器

如果期望本地缓存处理则自定义检测缓存 lookup

 

很显然,如果要检查缓存是需要根据什么方式做检查

判断缓存中是否存在对象,如果命中了 yes 于是交予 vcl_hit

就算命中了也有两条路可以走:

·deliver 直接由 vcl_deliver 在缓存中取出直接返回至用户

·如果命中了交予给 vcl_pass 通过自行手动控制了到后端缓存中去取的数据,有些时候有独特的控制机制

 

而 vcl_miss 也可以交由 vcl_pass 来处理

 

而为什么使用 pass

如果我们期望处理缓存的,比如要清理缓存,缓存中的内容找到则清理,如果没有找到则通过 pass 做一些处理

仅仅是提供用户编辑一些规则的而已

 

如果未命中,很先让必然要到后端去取 vcl_fatch

取完之后是否缓存下来就是在 fatch 中定义的

 

如果要缓存就先放着 cache 中,如果不想缓存则 Dont’Cache

最后再响应至客户端

 

 

因此用户请求到达 varnish 之后,varnish 大致要经过以上的处理阶段,而每个处理阶段要自定义处理规则对其做出处理,而有些功能只能在后端实现,有些只能在前端,不同的规则要在不同的位置实现的

 

VCL_RECV

vcl_recv 是在 Varnish 完成对请求报文的解码为基本数据结构后第一个要执行的子例程,它通常有四个主要用途:
(1) 修改客户端数据以减少缓存对象差异性;比如删除 URL 中的 www. 等字符;
(2) 基于客户端数据选用缓存策略;比如仅缓存特定的 URL 请求、不缓存 POST 请求等;
(3) 为某 web 应用程序执行 URL 重写规则;
(4) 挑选合适的后端 Web 服务器;

可以使用下面的终止语句,即通过 return() 向 Varnish 返回的指示操作:
pass:绕过缓存,即不从缓存中查询内容或不将内容存储至缓存中;
pipe:不对客户端进行检查或做出任何操作,而是在客户端与后端服务器之间建立专用“管道”,并直接将数据在二者之间进行传送;此时,keep-alive 连接中后续传送的数据也都将通过此管道进行直接传送,并不会出现在任何日志中;
lookup:在缓存中查找用户请求的对象,如果缓存中没有其请求的对象,后续操作很可能会将其请求的对象进行缓存;
error:由 Varnish 自己合成一个响应报文,一般是响应一个错误类信息、重定向类信息或负载均衡器返回的后端 web 服务器健康状态检查类信息;

vcl_recv 也可以通过精巧的策略完成一定意义上的安全功能,以将某些特定的攻击扼杀于摇篮中。同时,它也可以检查出一些拼写类的错误并将其进行修正等。

Varnish 默认的 vcl_recv 专门设计用来实现安全的缓存策略,它主要完成两种功能:
(1) 仅处理可以识别的 HTTP 方法,并且只缓存 GET 和 HEAD 方法;
(2) 不缓存任何用户特有的数据;

 

下面是一个自定义的使用示例:

sub vcl_recv {
    if (req.http.User-Agent ~ “iPad” ||

        req.http.User-Agent ~ “iPhone” ||

        req.http.User-Agent ~ “Android”) {

              set req.http.X-Device = “mobile”;
    } else {
              set req.http.X-Device = “desktop”;
    }
}

如果用户请求的时候浏览器用户代理是 iPad iPhone Android

那么于是将其设定首部为 mobile

否则就设标注首部为 desktop 桌面客户端

于是可以将其做响应处理了,比如如果是移动客户端将转为手机版服务器

如果是桌面客户端则转为正常 web 服务器

更多详情见请继续阅读下一页的精彩内容 :http://www.linuxidc.com/Linux/2014-07/104535p2.htm

安装配置 varnish

这里我们使用 yum 安装即可,但已将 rpm 包下载至本地

需要实现预装 gcc 因为 gcc 是需要编译 vcl 的

[root@node1varnish]# ll
total 872
-rw-r–r–. 1 root root 456232 Jul 16 13:53 varnish-3.0.4-1.el6.x8
-rw-r–r–. 1 root root 361784 Jul 16 13:53 varnish-docs-3.0.4-1.e
-rw-r–r–. 1 root root  43104 Jul 16 13:53 varnish-libs-3.0.4-1.e
-rw-r–r–. 1 root root  24572 Jul 16 13:53 varnish-libs-devel-3.0

进行安装

[root@node1varnish]# yum –nogpgchek localinstall *.rpm
[root@node1 varnish]# rpm -ql varnish

配置文件说明

[root@node1 varnish]# cd /etc/sysconfig/     

[root@node1sysconfig]# vim varnish

# 启动任何服务都需要对套接字进行解封,意为用户最多打开多少个文件

NFILES=131072      #65536*2 的结果,如果觉得多可以更改值

MEMLOCK=82000      #在内存中保存日志的空间区域大小,自己锁定区域的默认空间大小 82MB

NPROCS=”unlimited”  #所能够打开的进程数,对 linux 而言线程即进程,这里为无限定

RELOAD_VCL=1      #只要重启 varnish 都能够重新编译并重新载入 vcl,设置为 1 的话能够实现不用重启也能够重新编译 vcl 并使其生效

# 定义 varnish 工作特定参数:

# This file contains 4 alternatives,please use only one.

给了四种例子,但只能使用其中一种

所有的特性参数都使用 DAEMON_OPTS 进行定义

例子说明:

#DAEMON_OPTS=”-a:6081 \                                      #默认面向客户端的时候,监听在 6081 端口上
#            -Tlocalhost:6082 \                    #管理接口,可通过 vcladmin 命令连接进来,shiyi
#            -f/etc/varnish/default.vcl \                #服务器启动的时候自动加载 vcl 配置文件
#            -uvarnish -g varnish \           

#            -S /etc/varnish/secret \                    #秘钥文件,如果不加此参数的话就意味着任何主机都可以连接至此台节点
#            -sfile,/var/lib/varnish/varnish_storage.bin,1G”    #以文件的方式来缓存数据,最大大小为 1G

 

再来查看第三种方式,与第二种一样,只不过将参数都保存在变量里而已, 如下所示:

VARNISH_VCL_CONF=/etc/varnish/default.vcl        #vcl 配置文件路径

VARNISH_LISTEN_PORT=6081                        #启动端口

VARNISH_ADMIN_LISTEN_ADDRESS=127.0.0.1          #管理接口只监听在本地地址
VARNISH_ADMIN_LISTEN_PORT=6082

 

VARNISH_SECRET_FILE=/etc/varnish/secret          #SECRET 文件路径

VARNISH_MIN_THREADS=50                            #最小线程

VARNISH_MAX_THREADS=1000                          #最大线程数,每个线程用来接收一个用户请求
VARNISH_THREAD_TIMEOUT=120                        #线程的超时时间
VARNISH_STORAGE_FILE=/var/lib/varnish/varnish_storage.bin    #通过文件缓存的
VARNISH_STORAGE_SIZE=1G                            #缓存文件大小

VARNISH_STORAGE=”file,${VARNISH_STORAGE_FILE},${VARNISH_STORAGE_SIZE}” 

 

修改配置

系统配置文件位于 /etc/sysconfig/varnish

修改配置文件,明确指定其后端服务器,以及端口

backend default {

  .host = “10.0.10.62”;

  .port = “8080”;

}

 

如果想使用内存进行缓存数据的话,则可以修改如下参数:

VARNISH_MEMORY_SIZE=64M

VARNISH_STORAGE=”malloc,${VARNISH_MEMORY_SIZE}”

更改端口 6081 为 80

VARNISH_LISTEN_PORT=80

设置内存大小,这里先设置 64M 用于测试

VARNISH_MEMORY_SIZE=64M

更改 web 访问端口

VARNISH_LISTEN_PORT=80

设置管理接口的允许 IP 以及端口

VARNISH_ADMIN_LISTEN_ADDRESS=127.0.0.1

VARNISH_ADMIN_LISTEN_PORT=6082

 

启动 varnish

启动的前提需要启动后端 server,不然无法访问其地址,这里我们以 nginx 为后端

配置 nginx 过程略

[root@node1varnish]# /etc/init.d/nginx start

Startingnginx:                                          [OK]

启动 varnish

[root@node1varnish]# /etc/init.d/varnish start

Starting VarnishCache:                                  [OK]

查看监听端口

[root@node1varnish]# netstat -lntp | grep -E “80|6082”

tcp        0    0 0.0.0.0:80                0.0.0.0:*                  LISTEN      2102/varnishd     

tcp        0    0 0.0.0.0:8080              0.0.0.0:*                  LISTEN      2083/nginx         

tcp        0    0 127.0.0.1:6082            0.0.0.0:*                  LISTEN      2100/varnishd     

tcp        0    0 :::80                      :::*                        LISTEN      2102/varnishd 

访问 web 测试:

[root@node1varnish]# curl http://10.0.10.62:8080

node1

访问 varnish 测试

[root@node1varnish]# curl http://10.0.10.61

node1

 

连接 varnish

[root@node1sysconfig]# varnishadm –h
varnishadm: invalid option — ‘-‘
usage: varnishadm [-n ident] [-t timeout] [-S secretfile] -T [address]:portcommand […]
    -n is mutually exlusive with -S and -T

使用 - S 指定秘钥文件

使用 - T 指定服务器地址和端口,可以工作在交互模式和命令模式

[root@node1sysconfig]# varnishadm -S /etc/varnish/secret -T 127.0.0.1:6082
200     
—————————–
Varnish Cache CLI 1.0
—————————–
Linux,2.6.32-358.el6.x86_64,x86_64,-smalloc,-smalloc,-hcritbit
varnish-3.0.4 revision 9f83e8f

Type ‘help’ for command list.
Type ‘quit’ to close CLI session.

varnish> help  #输入 help 可以得到所有命令

常用命令

ping 可以测试当前是否正常

varnish> ping
200     
PONG 1405494395 1.0          #PONG 为正常 及返回响应状态

显示当前服务器状态

varnish> status
200     
Child in state running

关闭或启动某个子进程

varnish> stop
200     
varnish> start
200     
varnish> start
300     
Child in state running

显示当前正在使用的 vcl 文件

varnish>vcl.list
200     
active          0 boot

#active 状态 0 boot 表示启动的时候的 vcl 第 0 号 vcl

查看存储客户端

varnish>storage.list
200     
Storage devices:
    storage.Transient = malloc
    storage.s0 = malloc

# 一个存储客户端,名为 malloc.0

查看上游服务器

varnish>  backend.list

200       

Backend name                  Refs  Admin    Probe

default(10.0.10.62,,8080)    1      probe      Healthy (no probe)

 

使用 Chrome 浏览器调出开发人员界面观察其首部并观察

 

关键参数信息注释:

Cache-Control: no-cache #因为我们强行刷新了所以是 no-cache

Host:10.0.10.61        #响应的主机

Pragma:no-cache        #为了与 1.1 兼容

Via:1.1 varnish        #是否通过 varnish 转交

END, 感谢各位!

Varnish 的详细介绍 :请点这里
Varnish 的下载地址 :请点这里

varnish 基础概念详解

比起 squid 更加轻量级,大致有以下几个特点:

·可以基于内存缓存,也可以在磁盘上缓存,但是就算存放在磁盘上,也不能实现持久缓存

    只要进程崩溃,此前缓存统统失效,无论是在内存还是在磁盘,但是现在已经具备持久缓存功能,但是仍然在实验阶段,经常容易崩溃,而且最大大小不能超过 1G

    如果期望内存大小超过几十个 G,比如图片服务器,纯粹使用内存,性能未必好,这时候可以使用磁盘进行缓存,或 SSD X 2 做 RAID 避免磁盘损坏,在实现随机访问上 ssd 硬盘要比机械硬盘要好的多,如果必须要缓存在磁盘上还是建议使用 ssd 磁盘 

·可以利用虚拟内存方式,IO 性能会非常好

   

·支持设置 0 -60 秒 精确缓存时间

 

·支持 VCL

    其配置是通过 vcl 编程语言来完成的

    其配置需要先转换成 C 代码,所以使用 vcl 所写的配置,要先转换成 C 语言代码,因此要依赖于 GCC 临时的编译 vcl 配置的,编译完之后才能运行起来

 

·独特的日志存储及管理机制

    日志既然保存在内存中,日志可以供多个应用程序所访问,所以一般查看命中率,当前请求有多少 get post 方法等等,都需使用专用的工具才可以查看,比如 varnishshtopvarnishlog 等命令工具用来查看日志信息

 

·支持使用 varnish 状态引擎

    通过巧妙的状态引擎的设计完成不同的引擎对用户的请求和缓存代理机制进行处理,用配置文件为状态引擎提供状态法则,完成缓存处理、完成代理处理等等

 

·堆文件(缓存文件管理机制)非常独特,使用的二叉树来实现缓存对象管理,因此可以达到积极删除缓存管理

缓存服务器 Varnish 概念篇 http://www.linuxidc.com/Linux/2014-05/101389.htm

缓存服务器 Varnish 概念篇 http://www.linuxidc.com/Linux/2014-05/101389.htm

Varnish Cache 的架构笔记 http://www.linuxidc.com/Linux/2013-10/91016.htm

CentOS 5.8 下 Varnish-2.1.5 的安装配置 http://www.linuxidc.com/Linux/2013-09/89916.htm

RedHat 脚本改用 CentOS 源更新安装 Nginx、PHP 5.3、Varnish http://www.linuxidc.com/Linux/2012-07/65801.htm

利用 Varnish 构建 Cache 服务器笔记 http://www.linuxidc.com/Linux/2012-07/65234.htm

缓存服务 Varnish 安装配置 http://www.linuxidc.com/Linux/2012-07/65228.htm

Varnish 编译安装所需准备 http://www.linuxidc.com/Linux/2012-07/65230.htm

Linux 下 Varnish 缓存的配置优化 http://www.linuxidc.com/Linux/2012-03/56435.htm

 

varnish 工作机制

Varnish 基础概念详解 

varnish 启动后会生成主控进程 Management, 可以理解为 nginx 的 master 进程

它并不负责真正代理并构建响应的而是由各子进程 child/cache 来完成的

 

主进程主要负责:

提供了以下接口:

CLI interface 

Telnet Interface 

Web Interface

 

因此我们通常都是用 CLI 接口

通过此接口可以与进程进行实时的交互

 

 

而主控进程通常负责以下操作:

·通过命令行接口与命令行的控制指令进行交互

·管理各个子进程,确保每个子进程都能正常工作,如果某个子进程挂掉,则自动让其启动起来

·完成整个 varnish 的初始化,能够完成基于 vcl 的编译器去编译 VCL 的配置文件,并且检测 vcl 配置文件是否存在语法错误的,如果有语法错误则拒绝编译,因此对于配置文件的分析和启用是由主进程所去实现的,这样能够避免子进程加载错误配置从而导致缓存崩溃

 

编译好之后生成共享模块,可以供需要这些模块的子进程所使用

 

子进程主要负责内容有:

·子进程需要生成日志的,因为用户的请求以及自身构建的响应都是由子进程负责的,所以需要生成日志,日志是需要存放在指定日志文件中,日志文件实际是一段共享内存区域

这些内存共享区域需要一些专门观测的工具来观测服务器的工作状态的

 

·使用命令行接口与 CLI 命令行进行交互

·用来实现将可以缓存的数据缓存下来,并且构建数据 hash 表

·生成日志和状态

·接收用户的请求并构建响应

·与各后端 cache 进行响应

·woker threads 真正意义上接收用户请求并构建响应的内部的工作线程

·缓存失效功能管理

 

因此 varnish 也是 master/slave 的架构

对 varnish 而言,在命令行接口里,可以极大的控制子进程的特性的,比如线程池最大可以启动多少个工作线程等

所以工作线程数 x 每个线程池的数 = 能够接收多少用户请求数

所以这些都是可以设定的,这些设定完成可以命令行接口进行交互设定

 

vcl 的配置主要跟子进程内部的状态引擎有关系,也就是说子进程的工作方式如下:

 

当一个用户的请求到达之后,要解码整个用户的请求(查看请求的方式是 get 还是 post 等 )

如果是 GET 方法,这里肯定有缓存,因此是否需要先查缓存,都是需要对其控制的

如果缓存命中或未命中,如果命中则在缓存中取,如果未命中则直接去上游服务器取数据,取得数据是否缓存,那都取决于缓存机制

如果上游服务器告知可以缓存则缓存在本地,如果告知不可缓存则不缓存,比如跟 cookie 或日志相关的数据肯定不能缓存

所以这些机制都需要做监测的

 

例:

    上游服务器缓存的是图片,但是图片中加了 cookie,图片一般而言跟用户的关联不是很大,除非是邮件服务器,虽然图片的关联不大,但是加了 cookie,就没办法在多个用户之间共享缓存,那这种情况下需要将 cookie 删掉,将图片缓存,并且缓存很长时间

所以这些处理机制都需要在内部完成策略的,所以这些都需要在不同的步骤完成

所以所谓的状态引擎就是当一个用户的请求到达后,大致走到哪一层,我们在哪个步骤哪个位置大致做出哪些处理,这就为状态

在请求的报文在大致经过的位置,内置了几个状态引擎,在用户的请求到达状态引擎的时候,我们在其状态引擎上做规则并做出相应处理

 

状态引擎图解

Varnish 基础概念详解

 

椭圆形为状态引擎

菱形的为条件判断

每个颜色箭头下面的字符串为处理机制

 

首先用户请求到达后,首先进入 vcl_recv

vcl_recv 对其做判断,是否命中缓存 (vcl_hash)

如果不想使用缓存则直接交由 vcl_pipe, 建立管道并交由后端服务器

如果期望本地缓存处理则自定义检测缓存 lookup

 

很显然,如果要检查缓存是需要根据什么方式做检查

判断缓存中是否存在对象,如果命中了 yes 于是交予 vcl_hit

就算命中了也有两条路可以走:

·deliver 直接由 vcl_deliver 在缓存中取出直接返回至用户

·如果命中了交予给 vcl_pass 通过自行手动控制了到后端缓存中去取的数据,有些时候有独特的控制机制

 

而 vcl_miss 也可以交由 vcl_pass 来处理

 

而为什么使用 pass

如果我们期望处理缓存的,比如要清理缓存,缓存中的内容找到则清理,如果没有找到则通过 pass 做一些处理

仅仅是提供用户编辑一些规则的而已

 

如果未命中,很先让必然要到后端去取 vcl_fatch

取完之后是否缓存下来就是在 fatch 中定义的

 

如果要缓存就先放着 cache 中,如果不想缓存则 Dont’Cache

最后再响应至客户端

 

 

因此用户请求到达 varnish 之后,varnish 大致要经过以上的处理阶段,而每个处理阶段要自定义处理规则对其做出处理,而有些功能只能在后端实现,有些只能在前端,不同的规则要在不同的位置实现的

 

VCL_RECV

vcl_recv 是在 Varnish 完成对请求报文的解码为基本数据结构后第一个要执行的子例程,它通常有四个主要用途:
(1) 修改客户端数据以减少缓存对象差异性;比如删除 URL 中的 www. 等字符;
(2) 基于客户端数据选用缓存策略;比如仅缓存特定的 URL 请求、不缓存 POST 请求等;
(3) 为某 web 应用程序执行 URL 重写规则;
(4) 挑选合适的后端 Web 服务器;

可以使用下面的终止语句,即通过 return() 向 Varnish 返回的指示操作:
pass:绕过缓存,即不从缓存中查询内容或不将内容存储至缓存中;
pipe:不对客户端进行检查或做出任何操作,而是在客户端与后端服务器之间建立专用“管道”,并直接将数据在二者之间进行传送;此时,keep-alive 连接中后续传送的数据也都将通过此管道进行直接传送,并不会出现在任何日志中;
lookup:在缓存中查找用户请求的对象,如果缓存中没有其请求的对象,后续操作很可能会将其请求的对象进行缓存;
error:由 Varnish 自己合成一个响应报文,一般是响应一个错误类信息、重定向类信息或负载均衡器返回的后端 web 服务器健康状态检查类信息;

vcl_recv 也可以通过精巧的策略完成一定意义上的安全功能,以将某些特定的攻击扼杀于摇篮中。同时,它也可以检查出一些拼写类的错误并将其进行修正等。

Varnish 默认的 vcl_recv 专门设计用来实现安全的缓存策略,它主要完成两种功能:
(1) 仅处理可以识别的 HTTP 方法,并且只缓存 GET 和 HEAD 方法;
(2) 不缓存任何用户特有的数据;

 

下面是一个自定义的使用示例:

sub vcl_recv {
    if (req.http.User-Agent ~ “iPad” ||

        req.http.User-Agent ~ “iPhone” ||

        req.http.User-Agent ~ “Android”) {

              set req.http.X-Device = “mobile”;
    } else {
              set req.http.X-Device = “desktop”;
    }
}

如果用户请求的时候浏览器用户代理是 iPad iPhone Android

那么于是将其设定首部为 mobile

否则就设标注首部为 desktop 桌面客户端

于是可以将其做响应处理了,比如如果是移动客户端将转为手机版服务器

如果是桌面客户端则转为正常 web 服务器

更多详情见请继续阅读下一页的精彩内容 :http://www.linuxidc.com/Linux/2014-07/104535p2.htm

正文完
星哥玩云-微信公众号
post-qrcode
 0
星锅
版权声明:本站原创文章,由 星锅 于2022-01-20发表,共计12734字。
转载说明:除特殊说明外本站文章皆由CC-4.0协议发布,转载请注明出处。
【腾讯云】推广者专属福利,新客户无门槛领取总价值高达2860元代金券,每种代金券限量500张,先到先得。
阿里云-最新活动爆款每日限量供应
评论(没有评论)
验证码
【腾讯云】云服务器、云数据库、COS、CDN、短信等云产品特惠热卖中