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工作机制

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服务器