Varnish之一基础应用

一、Varnish简介

  Varnish是一款高性能的开源HTTP加速器(即带缓存的反向代理服务),可以把http响应内容缓存到内存或文件中,从而提高web服务器响应速度


二、Varnish程序结构

  varnish主要运行两个进程:Management进程和Child进程(也叫Cache进程):

  Management进程主要实现应用新的配置、编译VCL、监控varnish、初始化varnish以及提供一个命令行接口等。Management进程会每隔几秒钟探测一下Child进程以判断其是否正常运行,如果在指定的时长内未得到Child进程的回应,Management将会重启此Child进程。

  Child进程包含多种类型的线程,常见的如:

    Varnish依赖“工作区(workspace)”以降低线程在申请或修改内存时出现竞争的可能性。在varnish内部有多种不同的工作区,其中最关键的当属用于管理会话数据的session工作区。

    Acceptor线程:接收新的连接请求并响应;

    Worker线程:child进程会为每个会话启动一个worker线程,此worker线程真正来管理缓存,构建响应报文,因此,在高并发的场景中可能会出现数百个worker线程甚至更多;

    Expiry线程:从缓存中清理过期内容;

    wKiom1iAfX-hVrfjAAEHHUUEITU920.png-wh_50

三、Varnish日志管理

  Varnish通过可以基于文件系统接口进行访问的共享内存区域来记录日志,为了与系统的其它部分进行交互,Child进程使用了可以通过文件系统接口进行访问的共享内存日志(shared memory log),因此,如果某线程需要记录信息,其仅需要持有一个锁,而后向共享内存中的某内存区域写入数据,再释放持有的锁即可。而为了减少竞争,每个worker线程都使用了日志数据缓存。


  共享内存日志大小一般为90M,其分为两部分,前一部分为计数器,后半部分为客户端请求的数据。varnish提供了多个不同的工具如varnishlog、varnishncsa或varnishstat等来分析共享内存日志中的信息并能够以指定的方式进行显示。


  当日志区域超过90M后,默认情况下前面的日志将会被后面的日志覆盖,如果希望保存超出90M空间限制的日志,可以开启varnishncsa服务  


四、Varnish的缓存存储机制

  Varnish支持多种不同类型的后端存储,可用varnishd -s选项指定。后端存储的类型包括:

  file:自管理的文件系统,使用特定的一个文件存储全部的缓存数据,并通过操作系统的mmap()系统调用将整个缓存文件映射至内存区域(如果内存大小条件允许);varnish重启时,所有缓存对象都将被清除

  malloc:使用malloc()库调用在varnish启动时向操作系统申请指定大小的内存空间以存储缓存对象;varnish重启时,所有缓存对象都将被清除

  persistent:与file的功能相同,但可以持久存储数据(即重启varnish数据时不会被清除);仍处于测试期;


  注:varnish无法追踪某缓存对象是否存入了缓存文件,从而也就无从得知磁盘上的缓存文件是否可用,因此,file存储方法在varnish停止或重启时会清除数据。

  而persistent方法的出现对此有了一个弥补,但persistent仍处于测试阶段,例如目前尚无法有效处理要缓存对象总体大小超出缓存空间的情况,所以,其仅适用于有着巨大缓存空间的场景。

  选择使用合适的存储方式有助于提升系统性,从经验的角度来看,建议在内存空间足以存储所有的缓存对象时使用malloc的方法,反之,file存储将有着更好的性能的表现。然而,需要注意的是,varnishd实际上使用的空间比使用-s选项指定的缓存空间更大,一般说来,其需要为每个缓存对象多使用差不多1K左右的存储空间,这意味着,对于100万个缓存对象的场景来说,其使用的缓存空间将超出指定大小1G左右。另外,为了保存数据结构等,varnish自身也会占去不小的内存空间。


  各种存储方式的参数格式:

  file中的granularity用于设定缓存空间分配单位,也就是当我们size假设设置为20G,这20G的空间不是一次性分配的,而是初始时比方说分配1G,用完后,逐步增加,一次增加的多大(此即为granularity),默认单位是字节,一次次的增加,直到达到size大小

  malloc[,size]


  file[,path[,size[,granularity]]]


  persistent,path,size    


五、Varnish配置缓存策略工具:Vcl

  VCL(Varnish Configuration Language)是一种基于“域”(domain specific,可想象与iptables的几个链,也就是类似钩子函数)的简单编程语言,它支持有限的算术运算和逻辑运算操作、允许使用正则表达式进行字符串匹配、允许用户使用set自定义变量、支持if判断语句,也有内置的函数和变量等。

  使用VCL编写的缓存策略通常保存至.vcl文件中,其需要编译成二进制的格式后才能由varnish调用。事实上,整个缓存策略就是由几个特定的子例程如vcl_recv、vcl_hash等组成,它们分别在不同的位置(或时间)执行,如果没有事先为某个位置自定义子例程,varnish将会执行默认的定义。

  VCL策略在启用前,会由management进程将其转换为C代码,而后再由gcc编译器将C代码编译成二进制程序。编译完成后,management负责将其连接至varnish实例,即child进程。正是由于编译工作在child进程之外完成,它避免了装载错误格式VCL的风险。因此,varnish修改配置的开销非常小,其可以同时保有几份尚在引用的旧版本配置,也能够让新的配置即刻生效。编译后的旧版本配置通常在varnish重启时才会被丢弃,如果需要手动清理,则可以使用varnishadm的vcl.discard命令完成。


  1、VCL语法

  1)配置文件第一个非注释行必须是vcl 4.0,标明此vcl配置文件是基于vcl4.0版本;

  2)//、#或/ comment /用于单行或多行注释;

  3)sub $NAME 定义函数,子例程;

  4)不支持循环,支持条件判断,有内置变量;

  5)使用终止语句return(XXX),没有返回值,仅仅是标明下一步交给哪个状态引擎;

  6)域专用,语句用{ }括起来,用sub声明,指明为哪一段的专用代码,如:sub vcl_recv{…},可理解为一个配置段;

  7)每个语句必须以;分号结尾;

  8)每个变量有其能使用的引擎的位置,可理解为变量由其可用的配置段;

  9)操作符:=(赋值)、==(等值比较)、~(模式匹配)、!(取反)、&&(逻辑与)、||(逻辑或)、>(大于)、>=(大于等于)、<(小于)、<=(小于等于);


  注意,各个状态引擎有其默认的配置,无论各个vcl引擎内的配置如何修改,该状态引擎的默认的配置都会自动附加在修改的配置之后生效

  查看默认的配置可以用:varnishadm -S /etc/varnish/secret -T 127.0.0.1:6082 –> vcl.show -v 配置名称 


  2、VCL工作原理:

  wKiom1iAfY-ST2i5AADLlRH0dX0515.jpg-wh_50


  3、关键参数解析:

    vcl_recv:接受用户请求进varnish的入口的引擎,接受到结果之后,利用return(lookup),将请求转交给vcl_hash引擎进行处理

    vcl_hash:接受到用户请求后,对用户请求的URL进行hash计算,根据请求的首部信息,以及hash结果进行下一步处理的引擎

    vcl_hit:经过vcl_hash引擎处理后,发现用户请求的资源本地有缓存,则vcl_hash引擎通过return(hit)将请求交给vcl_hit引擎进行处理,vcl_hit引擎处理后将请求交给vcl_deliver引擎,vcl_deliver引擎构建响应报文,响应给用户

    vcl_miss:经过vcl_hash引擎处理后,发现用户请求的资源本地没有缓存,则vcl_hash引擎通过return(miss)将请求交给vcl_miss引擎进行处理

    vcl_purge:经过vcl_hash引擎处理后,发现请求是对缓存的内容进行修剪时,则通过return(purge)交给vcl_purge引擎进行处理,vcl_purge引擎处理后,利用vcl_synth引擎将处理的结果告知给用户

    vcl_pipe:经过vcl_hash引擎处理后,发现用户请求的报文varnish无法理解,则通过return(pipe),将请求交给vcl_pipe引擎,pipe引擎直接将请求交给后端真实服务器

    vcl_pass:当请求经过vcl_hash处理后,发现请求报文不让从缓存中进行响应或其他原因没办法查询缓存,则由return(pass)或return(hit-for-pass)交由vcl_pass引擎进行处理

    vcl_backend_fetch:当发现缓存未命中或由vcl_pass传递过来的某些不能查询缓存的请求,交由vcl_backend_fetch引擎处理,vcl_backend_fetch引擎会向后端真实web服务器发送请求报文,请求对应的资源

    vcl_backend_response:当后端发送响应报文到varnish后,会由vcl_backend_resonse引擎进行处理,如:判断响应的内容是否可缓存,如果能缓存,则缓存下来后,交给vcl_deliver引擎,如果不能缓存,则直接交给vcl_deliver引擎,vcl_deliver引擎构建响应报文给客户端

    varnish4.0版本的两个特殊的引擎

    vcl_init:在处理任何请求之前要执行的vcl的代码,主要用于初始化VMODS,可用在后端主机有多台时,借助此引擎完成多台主机的负载均衡效果

    vcl_fini:所有的请求都已经结束,在vcl配置被丢弃时调用;主要用于清理VMODS  


  4、常用缓存处理情况流程

  缓存命中情况:

    用户请求–>vcl_recv–>vcl_hash–>vcl_hit–>vcl_deliver–>响应给用户

  缓存未命中情况:

    用户请求–>vcl_recv–>vcl_hash–>vcl_miss–>vcl_backend_fetch–>后端服务器接受请求发送响应报文–>vcl_backend_response–>vcl_deliver

  或:

    用户请求–>vcl_recv–>vcl_hash–>vcl_miss–>vcl_pass–>vcl_backend_fetch–>后端服务器接受请求发送响应报文–>vcl_backend_response–>vcl_deliver–>响应给用户

  不能从缓存中进行响应:

    用户请求–>vcl_recv–>vcl_hash–>vcl_pass–>vcl_backend_fetch–>后端服务器接受请求发送响应报文–>vcl_backend_response–>vcl_deliver–>响应给用户

  进行缓存修剪:

    用户请求–>vcl_recv–>vcl_hash–>vcl_purge–>vcl_synth–>返回给用户

  请求报文无法理解:

    用户请求–>vcl_recv–>vcl_hash–>vcl_pipe–>交给后端服务器


  5、VCL常见内建函数

  regsub(str,regex,sub)和regsuball(str,regex,sub):这两个用于基于正则表达式搜索指定的字符串并将其替换为指定的字符串;但regsuball()可以将str中能够被regex匹配到的字符串统统替换为sub,regsub()只替换一次;

  ban(expression):清除能被表达式匹配的所有缓存对象

  ban_url(regex):清除所有其URL能够由regex匹配的缓存对象;

  hash_data(str):对指定的字符串做hash计算后的结果

  return():当某VCL域运行结束时将控制权返回给Varnish,并指示Varnish如何进行后续的动作;其可以返回的指令包括:lookup、hash、hit、miss、pass、pipe、hit_for_pass、purge等;但某特定域可能仅能返回某些特定的指令,而非前面列出的全部指令;

  return(restart):重新运行整个VCL,即重新从vcl_recv开始进行处理;每一次重启都会增加req.restarts变量中的值,而max_restarts参数则用于限定最大重启次数。

  注:VCL的函数不接受参数并且没有返回值,VCL内部的数据传递只能隐藏在HTTP首部内部进行。VCL的return语句用于将控制权从VCL状态引擎返回给Varnish进程,而非默认函数,这就是为什么VCL只有终止语句而没有返回值的原因。同时,对于每个“域”来说,可以定义一个或多个终止语句,以告诉Varnish下一步采取何种操作,如查询缓存或不查询缓存等。


  6、常见内建变量

  1)req.*:req.开头的变量,由客户端发来的http请求相关的变量


  如:

  req.method  表示客户端的请求方法

  req.url  表示客户端请求的url

  req.http.host  表示客户端请求报文的主机

  req.http.*  *可以是http请求报文的任意首部的名称,代表引用http的某个请求首部

  req.http.HEADERS: 表示客户端发送给varnish的请求报文中的某个首部

  req.request: 表示客户端发送给varnish的请求报文的请求方法(4.0版本的varnish改为了req.method)

  req.url:表示客户端发送给varnish的请求报文的请求的url

  req.proto:表示客户端发送给varnish的请求报文的http协议的协议版本


  2)bereq.* :bereq.开头的变量,varnish主机在向后端真实服务器发送http请求报文时的相关变量


  如:可以将真实的客户端地址传递给后端真实web服务器,以便于后端真实服务器记录客户端的真实IP,而不是varnish的IP 

  breq.http.* 代表varnish发往后端的真实的web服务器的相关的请求报文中的首部

  bereq.http.HEADERS: 表示varnish发往后端真实web服务器的请求报文中的某个首部

  bereq.request: 表示varnish发往后端真实web服务器的请求报文的请求方法(4.0版本的varnish改为了bereq.method)

  bereq.url:表示varnish发往后端真实web服务器的请求报文的请求的url

  bereq.proto:表示varnish发往后端真实web服务器的请求报文的http协议的协议版本

  bereq.backend:表示要varnish发送请求到后端真实web服务器时,后端服务器不止一台时,所调用的后端主机


  3)beresp.*:beresp.开头的变量,由后端真实服务器发来的http响应报文中的某些首部信息相关的变量,一般是在vcl_backend_response或vcl_backend_fenth引擎中调用

  如:

  beresp.http.HEADERS:表示后端真实web服务器发给varnish的http响应报文的某个首部的信息

  beresp.proto:表示后端真实web服务器发给varnish的http响应报文的http协议版本

  beresp.status:表示后端真实web服务器发给varnish的http响应报文的响应状态码

  beresp.backend.name:表示后端真实web服务器发给varnish的http响应报文的后端主机的名称

  beresp.ttl:后端服务器响应中的内容的余下的生存时长  


  4)resp.*:resp.开头的变量,由varnish响应给客户端的响应报文相关的变量,一般用在vcl_deliver引擎中进行调用,因为deliver引擎是用于给客户端构建响应报文,发送响应报文


  resp.http.: 可以是响应报文中的任意首部的名称,代表引用某个响应报文的值,可用于设定、添加、修改响应给客户端的响应报文中的响应首部的值

  resp.http.HEADERS:表示varnish发送给客户端的响应报文的某个首部的信息

  resp.proto:表示varnish发送给客户端的http响应报文的http协议版本

  resp.status:表示varnish发送给客户端的http响应报文的响应状态码


  5)obj.* :obj.开头的变量,对存储在缓存空间中的缓存对象属性的引用变量。obj开头的变量都是只读的


  如:

  obj.hits: 某个缓存对象的缓存的命中次数

  obj.ttl 此对象的ttl值,也就是其缓存时长 


  6)client.,server.,storage.*:可用在所有面向客户端一侧的引擎中,也就是vcl_recv、vcl_pipe、vcl_hash、vcl_pass、vcl_purge、vcl_miss、vcl_hit、vcl_deliver、vcl_synth中


  如:

  client.ip  代表客户端的IP地址

  server.ip  代表当前varnish的IP地址

  client.port  代表客户端的端口

  server.port  代表当前varnish的端口

  server.hostname 当前varnish的主机名


  7)用户自定义变量

  可用set,来设定某个用户自定义变量或现有变量的值

  如:

  set resp.http.X-Cache = "HIT" :表示设定响应给客户端的响应报文中设定X-Cache首部的值为HIT

  set resp.http.IS-Cache = "YES"+" "server.ip  :表示设定响应给客户端的响应报文中的IS-Cache首部的值为"YES varnish服务器IP",多个元素之间要用+加号连接,如果要输出空格,需要用""引号引起来


  可用unset,来取消某个用户自定义变量,或删除现有变量

  如:

  unset req.http.cookie :表示取消客户端请求报文中http的cookie首部信息

  unset beresp.http.Set-cookie :表示取消后端服务器发送到varnish上的响应报文http首部中的Set-cookie首部


六、目前常见几款缓存工具对比与区别:

  Squid:是功能最全面的,但架构太老,性能一般,不能支持多核,支持ACL控制,支持ICP缓存协议,支持外部规则文件读取、热加载、热启动

  Varnish:是内存缓存,速度一流,但是内存缓存也限制了其容量,一般多用于缓存页面和图片,不支持集群,支持后端活检查,不支持外部文件读取,需要转义,支持热启动,支持多核

  Nginx:本来是反向代理/web服务器,使用插件,但是本身不支持特性较多,不支持外部文件读取,需要转义,支持热启动,支持多核

  ATS:目前是一个不错的选择,支持多核,磁盘/内存缓存,性能强,支持插件开发、ICP协议、外部文件读取、热加载、热启动,但缺乏文档


七、补充扩展一:http缓存浅析

  1、http缓存处理的步骤:

    接受请求–>解析请求(提取请求的URL及各种首部)–>查询缓存–>判断缓存的有效性–>构建响应报文–>发送响应–>记录日志

  注:http首部信息缓存相关参数

    expire:缓存的有效期限,是一个绝对时间,如2016-11-11 08:08:08类似

    if-modified-since:表示基于last-modified机制,缓存服务器到后端真实服务器上判断缓存有效性时,判断自从某个绝对时间点后,缓存内容是否发生过更改

    if-none-match:基于Etag机制,用于缓存服务器向后端服务器验证缓存有效性

    public:可被所有公共缓存缓存,尽可以在响应报文中

    private

    no-store:在响应报文中表示该内容不可缓存,在请求报文中表示不能从缓存中进行响应

    no-cache:在响应报文中表示可以缓存,但是客户端端请求的内容缓存命中后,不能直接用缓存直接响应,而是要先到原始服务器上进行校验缓存有效性。在请求报文中表示要先到原始服务器上进行校验有效性后才能用缓存的内容进行响应

    max-age:以秒为单位指定的相对时长(300000),表示缓存的最大有效期,是一个相对时长,与expire类似,但是expire给明的有效期是绝对日期(2016-11-11 08:08:08类似)

    s-maxage:与max-age类似,但是仅仅作用于公共缓存  


八、补充扩展二:如何有效控制缓存

  1、过期日期控制:

    HTTP/1.0响应报文首部中的过期日期机制:

    Expires:Mon, 28 Sep 2017 01 :00 :31 GMT 指明了具体过期的时间和日期


    HTTP/1.1响应报文首部中的过期日志机制:

    Cache-Control:max-age=31104000 max-age指明了一个相对时长,可缓存多少秒


  2、通过Cache-Control缓存控制:

    no-cache:通知缓存服务器,必须要进行验证缓存的新鲜性,否则不会接受任何缓存文档(在浏览器中用Ctrl+F5就是实现了此种功能)

    no-strore:告知缓存服务器,必须尽快删除缓存中的文档(可能是因为其包含用户的敏感信息)

    max-age:相对的时间,类似于Expires首部的效果一样,只是相对时长,如300000之类的数字,默认单位为秒

    max-stale:告知缓存服务器,可以使用任意缓存文件(包括过期的文件进行响应)

    min-fresh:


    对响应首部可接受的参数:

    public:可以放在公共缓存上,公共缓存是指除了客户端的自身浏览器的缓存,其他任何位置都是公共缓存

    private:可以放在私有缓存上进行缓存

    no-cache:表示能缓存,但是当客户端下次请求同样的资源时,不能直接用缓存的内容响应给客户端,而是要到原始服务器验证缓存的有效性

    no-store:不可缓存,表示响应的内容不允许缓存

    must-revalidate:必须重新校验,表示内容缓存下来后,当用户请求同样的内容时,必须要原始服务器上进行校验缓存有效性

    max-age:可缓存的时长,相对时长,也就是从此刻开始,可以缓存多少秒

    s-max-age:公共缓存服务器的缓存,可缓存的时长。控制公共缓存最大有效期,如果没有公共缓存的定义,也能使用私有缓存中的数据(也就是s-max-age可以不用指明,但是如果没有指明,如果公共缓存中的数据需要缓存,缓存的有效时长就取决于max-age)

  


  3、新鲜度检测的缓存机制

    文档过期机制:在有效期内,利用的都是缓存的内容,此种方式有可能造成,当缓存有效,但实际服务器上的数据已经发生变化,而用户看到的内容依然是缓存的内容


    在HTTP/1.0版本中,有个首部叫Expires(过期时间),使用的是绝对时间,如2016-10-18 18 :28 :58类似这种指明具体的绝对的过期时间

    在HTTP/1.1版本中,有个首部叫Cache-Control字段中有一个叫max-age=XX的字段用来控制,使用的是相对时长,如可以使用2000秒


    条件式请求:基于时间的条件式请求:mtime: if-modified-since|if-Unmodified-Since

    相当于客户端发送请求,缓存服务器收到请求后,如果缓存服务器缓存有请求的资源,不会直接使用该资源响应用户请求,而是缓存服务器去向原始服务器询问,是否有该资源,如果没有资源,则证明缓存的已经没用了,就返回给客户端没有对应的资源;如果实际服务器上有对应的资源,缓存服务就将自己缓存的资源的时间戳提供给原始服务器,询问原始服务器上资源在此时间戳之后有没有发生过修改,如果没有发生过修改,原始服务器则返回304,Not Modified给缓存服务器,证明缓存服务器上的资源与原始服务器的资源是一致的,如果在时间戳之后发生过修改,则原始服务器将修改后的资源重新发送给缓存服务器,缓存服务器重新缓存,然后发送给客户端


    基于扩展标签的条件式请求 :ETag : if-none-match|if-Match

    想象此类情况:当请求的资源的时间戳发生了改变,但是文件内容却没有发生改变(如touch现有的文件);或者有些文件的内容修改的速度非常快,在毫秒级别,但是文件的时间戳只能精确到秒级别,此时就会发现文件的时间戳没变,但是文件内容已经发生改变

    此种情况下,我们给每个文件一个版本号(专业称呼为:扩展标记ETag),一旦文件内容发生改变,扩展标记就会发生改变,内容不变,扩展标记也不变,当缓存服务器与后端服务器进行比对时,就是比对扩展标记,如果扩展标记不一致,就重新缓存,这样就实现了基于文件内容的判断机制


    注:文件有效期机制和条件式请求机制的结合使用:在文档有效期内,用缓存的内容去响应,但是当文档有效期到期后,不是立即到后端服务器上请求新内容来覆盖缓存服务器上的原有缓存内容,而是通过条件式请求机制(if-modified-since或if-none-match)去向后端真实服务器,判断当前缓存服务器上的缓存与后端服务器上的真实数据是否一致,如果一致,则继续使用


    文档过期机制(Expires和Cache-Control:max-age=)一般是在响应首部中,而条件式请求机制(if-modified-since或if-none-match)一般出现在请求首部中

    

九、Varnish安装

  系统环境:CentOS7.2 

  关闭防火墙:#systemctl stop firewalld.service 

  Varnish软件包版本:Varnish-4.0.4

  建议配置yum源:163源或阿里源

  1、解决依赖关系

  [root@moni ~]#yum install -y autoconf automake libedit-devel libtool ncurses-devel pcre-devel pkgconfig python-docutils python-sphinx


  2、yum安装(源码包:http://repo.varnish-cache.org/source)

 

 [root@moni ~]# yum isntall -y varnish


  安装完成后,关键配置文件说明:

  服务监听的端口默认为6081

  管理接口默认监听的端口为6082


  /etc/varnish/varnish.params: #配置varnish服务进程的工作特性,官方提供的rpm包安装的程序,其对应的程序自身配置文件在/etc/sysconfig/varnishd,例如监听的地址和端口,缓存机制;

  /etc/varnish/default.vcl:#配置各Child/Cache线程的工作属性;

  主程序:/usr/sbin/varnishd

  命令行管理工具程序:/usr/bin/varnishadm

  Shared Memory Log交互工具:

      /usr/bin/varnishhist

      /usr/bin/varnishlog

      /usr/bin/varnishncsa

      /usr/bin/varnishstat

      /usr/bin/varnishtop    


  VCL配置文件重载程序:#/usr/sbin/varnish_reload_vcl

  Systemd Unit File:

      /usr/lib/systemd/system/varnish.service  #varnish服务

      /usr/lib/systemd/system/varnishlog.service #日志持久的服务

      /usr/lib/systemd/system/varnishncsa.service    

  3、Varnish程序配置文件说明(/etc/varnish/varnish.params)

  RELOAD_VCL=1   #设置为1表示当使用systemctl reload varnish时,会自动重新装载vcl的配置文件,也就是能够让新的配置生效


  VARNISH_VCL_CONF=/etc/varnish/default.vcl   #加载的缓存策略的配置文件路径


  #VARNISH_LISTEN_ADDRESS=      #varnish服务监听的地址,默认是监听在本机所有可用的地址上


  VARNISH_LISTEN_PORT=6081    #varnish监听的端口,因为varnish要作为web服务器的反代进行工作时,才能将http的内容缓存,因此,一般要将其改为80端口,但是实际生产环境中,varnish一般是处于前端调度器的后面,所以可以在前端调度器上将调度的端口改为此处的端口也可以


  VARNISH_ADMIN_LISTEN_ADDRESS=127.0.0.1    #varnish管理接口监听的地址,监听在127.0.0.1表示只允许从本机登录进行管理


  VARNISH_ADMIN_LISTEN_PORT=6082    #varnish管理接口监听的端口


  VARNISH_SECRET_FILE=/etc/varnish/secret   #varnish管理时的秘钥文件


  VARNISH_STORAGE="file,/var/lib/varnish/varnish_storage.bin,1G"   #varnish缓存时,使用哪种存储方式对缓存内容进行存储,本处是指使用file文件方式,存在/var/lib/varnish/varnish_storage.bin文件中,总共使用1G大小的空间

      如果要使用内存缓存,则可以定义为:"malloc,400M"

      在很多生产环境还是使用file,但是将文件放在固态硬盘,如果希望性能更好点,放在PCI-E的固态硬盘


  VARNISH_TTL=120   #如果后端服务器没有指明缓存内容的TTL时间,则varnish自身为缓存定义的TTL时间

  VARNISH_USER=varnish

  VARNISH_GROUP=varnish


  注:以上选项,实际是varnishd运行时调用时读取的变量,实际还有很多参数要指明,如varnish线程池的数量,以及每个线程池的线程数,此时要在varnish程序自身的配置文件中,利用

  DAEMON_OPTS="-p thread_polls=2 -p thread_pool_min=100 -p thread_pool_max=5000 -p thread_pool_timeout=300"

  用-p指明参数和对应的值,其指明的选项有很多,具体可以参照man varnishd手册


  4、启动服务并确认端口是否正常监听

  [root@moni yum.repos.d]# systemctl start varnish.service
  [root@moni yum.repos.d]# ss -ltnp |grep 'varnishd'
  LISTEN     0      128          *:6081                     *:*                   users:(("varnishd",pid=24264,fd=6))
  LISTEN     0      10     127.0.0.1:6082                     *:*                   users:(("varnishd",pid=24262,fd=5))
  LISTEN     0      128         :::6081                    :::*                   users:(("varnishd",pid=24264,fd=7))