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工作机制
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删掉，将图片缓存，并且缓存很长时间
所以这些处理机制都需要在内部完成策略的，所以这些都需要在不同的步骤完成
所以所谓的状态引擎就是当一个用户的请求到达后，大致走到哪一层，我们在哪个步骤哪个位置大致做出哪些处理，这就为状态
在请求的报文在大致经过的位置，内置了几个状态引擎，在用户的请求到达状态引擎的时候，我们在其状态引擎上做规则并做出相应处理
状态引擎图解
椭圆形为状态引擎
菱形的为条件判断
每个颜色箭头下面的字符串为处理机制
首先用户请求到达后，首先进入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服务器
安装配置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,感谢各位！
184
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
