关于varnish缓存


引言:缓存的概念

熟悉一些名词:

  • 时间局部性:一个数据被访问过之后,可能很快会被再次访问到;
  • 空间局部性:一个数据被访问时,其周边的数据也有可能被访问到

  • 数据缓存:例如MySQL到web应用服务器之间的缓存,服务器缓存的资源是数据缓存
  • 页面缓存:接入层和应用层中间的缓存,服务器缓存的是可缓存的页面,这层就是缓存层

  • 缓存命中率:hit/(hit+miss),一般高于30%命中率则是正向收益,好的设计系统可以达到80%到95%以上
  • 字节命中率:按照数据的字节大小来计算命中率
  • 请求命中率:按照请求的数量来计算命中率

  • 代理式缓存:客户端访问缓存服务器,缓存服务器没有命中缓存时到后端服务器请求数据,此时它作为反向代理服务器工作,这种类型的缓存服务器叫做代理式缓存
  • 旁挂式缓存:客户端亲自去查询数据库,并且将数据复制给缓存服务器一份,下次先去找缓存服务器,如果没有命中则再去数据库服务器查询,此时这种工作方式的缓存叫做旁挂式缓存,这个客户端叫做胖客户端(smart client)

  • private cache:私有缓存,用户代理附带的本地缓存机制
  • public cache:公共缓存,反向代理服务器的缓存功能

  • CND:Content Delivery Network 内容投递系统

  • GSLB:全网均衡调度

  • 缓存有效性判断机制
    • 过期时间
    • 条件式验证
      • Last-Modified/If-Modified-Since:基于文件的修改时间戳来判别
      • Etag/If-None-Match:基于文件的校验码来判别

“过期时间验证”缓存是否失效颗粒度太大,如果页面刚刚缓存应用服务器发生了变化,结果客户端拿到的就是过期数据;从而加入了条件式验证缓存的失效性,每次客户端请求到达缓存服务器,缓存服务器都要拿本地的数据和应用服务器的数据比较时间戳,如果时间戳发生了变化则缓存新的数据;这样虽然粒度小了,但是还是会有问题,如果应用服务器在同一秒页面数据变化了三次,而缓存服务器拿到的是第一份数据,这样还是会发生数据失效的问题;从而又引入了Etag(扩展标记)来标记唯一的页面数据。此时虽然解决了数据失效性的问题,但是每次客户端的请求都要去后端服务器做比较,对缓存和应用服务器都是不小的压力,我们不得不采取折中的解决方案就是“过期时间验证+条件式验证”,将不经常变动的页面做过期时间验证,变动频繁的采用条件式验证。

请求报文用于通知缓存服务如何使用缓存响应请求:

cache-request-directive = 
"no-cache" 不能使用缓存系统中的缓存响应我,必须先去应用服务器做缓存验证
"no-store" 不能使用缓存系统中的缓存响应我,必须去应用服务器请求响应我
"max-age" "=" delta-seconds 
"max-stale" [ "=" delta-seconds ]
"min-fresh" "=" delta-seconds
"no-transform"
"only-if-cached"
cache-extension

响应报文用于通知缓存服务器如何存储上级服务器响应的内容:

cache-response-directive =
"public" 所有缓存系统都可以缓存
"private" [ "=" <"> 1#field-name <"> ] 仅能够被私有缓存所缓存
"no-cache" [ "=" <"> 1#field-name <"> ],可缓存,但响应给客户端之前需要revalidation,即必须发出条件式请求进行缓存有效性验正
"no-store" ,不允许存储响应内容于缓存中
"no-transform" 不能转换格式
"must-revalidate" 必须重新验证
"proxy-revalidate" 
"max-age" "=" delta-seconds 私有缓存最大缓存时长
"s-maxage" "=" delta-seconds 公共缓存最大缓存时长
cache-extension

Web Page Cache解决方案:squid和varnish,它们的关系就像Apache和Nginx

一、varnish缓存

1. 简介

Varnish cache,是一套高性能的开源反向网站缓存服务器(reverse proxy server)、HTTP加速器 ,很多门户网站已经部署了varnish,并且性能要比squid高上许多,甚至比squid还稳定,且效率更高,资源占用更少。

特点:

  • Varnish可以使用内存也可以使用硬盘进行数据缓存
  • 支持虚拟内存的使用
  • 有精确的时间管理机制
  • 状态引擎架构:通过特定的配置语言设计不同的语句
  • 以二叉堆格式管理缓存数据

优势:

  • 稳定性强:将worker单独分开;
  • 速度快:采用“page Cache”技术,所有缓存数据直接从内存读取;
  • 支持多并发;
  • 通过管理端口,使用正则批量清除部分缓存;或者通过页面清;
  • 通过fork打开多进程处理

劣势:

  • 进程一旦crash或重启,缓存的数据将从内存中完全释放
  • 在多台varnish实现负载均衡时,每次请求都会落到不同的varnish服务器中,造成url请求可能会穿透到后
  • 劣势解决方案
    • a. 在varnish的后端添加squid/nignx代理,这样防止了当varnish缓存被清空时,瞬间大量的请求发往web服务器
    • b. 在负载均衡上做url哈西,让单个url请求固定请求到一台varnish服务器上

2. 总体结构

64380cd

如上图所示,主要进程:Management、Cacher。

2.1 两个主进程

2.1.1 Management进程

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

Manager管理的接口

  • CLI interface :命令行接口
  • Telnet interface :telnet接口
  • Web interface :Web管理接口

2.1.2 Child/Cacher进程

进程包括多个线程

  • Accept 线程:接收新的连接请求并响应
  • Worker 线程:child进程会为每个会话启动一个worker线程,因此,在高并发的场景中可能会出现数百个worker线程甚至更多;
  • Object Expiry 线程:从缓存中清理过期内容;
  • Commad line 线程 : 管理接口
  • Storage/hashing 线程 :缓存存储
  • Log/stats 线程:日志管理线程
  • Backend Communication 线程:管理后端主机线程
  • Varnish依赖“工作区(workspace)”以降低线程在申请或修改内存时出现竞争的可能性。在varnish内部有多种不同的工作区,其中最关键的当属用于管理会话数据的session工作区。

2.2 Varnish的日志

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

varnish提供了多个不同的工具如varnishlog、varnishncsa或varnishstat等来分析共享内存日志中的信息并能够以指定的方式进行显示。

2.3 VCL—varnish配置缓存策略的工具

Varnish Configuration Language(VCL)是varnish配置缓存策略的工具,它是一种基于域(domain specific)的简单编程语言,它支持有限的算术运算和逻辑运算操作、允许使用正则表达式进行字符串匹配、允许用户使用set自定义变量、支持if判断语句,也有内置的函数和变量等。

使用VCL编写的缓存策略通常保存至.vcl文件中(默认文件:$varnish_home/default.vcl,其需要编译成二进制的格式后才能由varnish调用,即编写的.vcl文件由VCL compiler来编译,VCL compiler调用C compiler来编译后由management来读取生效(读取是及时的),编译后management让各Child进程来应用生效(因为编译成sharedobject为各子进程各读取了一份)。事实上,整个缓存策略就是由几个特定的子例程如vcl_recv、vcl_fetch等组成,它们分别在不同的位置(或时间)执行,如果没有事先为某个位置自定义子例程,varnish将会执行默认的定义。

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

[VCL的工作流程]
vcl处理流程

(1)Receive 状态,也就是请求处理的入口状态,根据 VCL 规则判断该请求应该是 Pass 或Pipe,或者进入 Lookup(本地查询)。
(2)Lookup 状态,进入此状态后,会在 hash 表中查找数据,若找到,则进入 Hit 状态,否则进入 miss 状态。
(3)Pass 状态,在此状态下,会进入后端请求,即进入 fetch 状态。
(4)Fetch 状态,在 Fetch 状态下,对请求进行后端的获取,发送请求,获得数据,并进行本地的存储。
(5)Deliver 状态, 将获取到的数据发送给客户端,然后完成本次请求。

二、Varnish的工作模式(more)

说在前面:关于“内置函数/状态引擎”这两个名词概念:你只需记住varnish的缓存策略是基于vcl进行编写的,因此可以叫vcl内置函数/vcl状态引擎,也可以叫做varnish内置函数/varnish状态引擎;“内置函数”与”状态引擎“大致可以理解为同一事物的不同体现,”内置函数“可以在.vcl文件中直接体现,而”状态引擎“是”内置函数“在实现缓存的处理过程的一种抽象,怎么理解就见仁见智吧。

1. 状态引擎的处理流程

上面提到VCL是配置varnish缓存策略的工具,因此缓存的处理流程还是围绕VCL展开。
缓存策略的进行是由vcl状态引擎来实现的,所谓的状态引擎就是当一个用户请求到达后,根据处理逻辑到达不同阶段,在每个阶段中需要做出的处理动作可以理解为这个状态。

varnish工作流


详细流程
缓存策略在vcl状态引擎的体现

  • 图椭圆形部分称为varnish的状态节点,又称为vcl状态引擎,还有种叫法为varnish的vcl内置函数
  • 红色的线条:没有查询缓存/缓存中数据过期/缓存中没有数据 情况下的流程
  • 橙黄色的线条:直接将匹配数据通过内置函数vcl_pipe送往后台主机的流程
  • 绿色的线条:查询缓存数据命中且数据没有过期/经后台主机返回的数据经被缓存后返回给客户流程
  • 蓝色的线条:数据没有命中缓存向后台主机发出查询的流程
  • 黑色的线条:数据从后台主机返回给varnish缓存的流程

2. Vcl内置函数和状态引擎的核心

2.1 Vcl内置函数

基于vcl配置的varnish缓存策略,(结合上节)总结其作用如下:

vcl_recv:用于接受和处理请求。当请求到达并成功接收后被调用,通过判断请求的数据来决定如何处理请求。例如如何响应、怎么响应、使用哪个后端服务器等。
vcl_fetch:根据服务器端的响应作出缓存决策,如判断获取的内容来决定是将内容放入缓存,还是直接返回给客户端。
vcl_pipe:对于无法理解的用户请求,将请求直接发往后端主机;
vcl_hash:自定义hash生成时的数据来源
vcl_pass:用于将请求直接传递至后端主机,后端主机在应答数据后将应答数据发送给客户端,但不进行任何缓存。
vcl_hit:从缓存中查找到缓存对象时要执行的操作;
vcl_miss:从缓存中款查找到缓存对象时要执行的操作;
vcl_deliver:将用户请求的内容响应给客户端时用;
vcl_error:在varnish端合成错误响应而时;

因此,其大致流程可分为如下:

vcl_recv-->vcl_hash-->vcl_hit-->vcl_deliver
vcl_recv-->vcl_hash-->vcl_miss-->vcl_fetch-->vcl_deliver
vcl_recv-->vcl_pass-->vcl_fetch-->vcl_deliver
vcl_recv-->vcl_pipe

Engine

2.2 vcl的配置语法

(1) //, #, /*comment*/用于注释;
(2) sub $NAME 用于定义函数;
(3) 不支持循环;
(4) 有众多内置变量;
(5) 支持终止语句,没有返回值;
(6) “域”专用语言;
(7) 操作符: =, ==, ~, !, &&, ||

pipe 无法理解请求方法,管道直接送到后台
pass 不查缓存

常用语句

if else
set name=value
unset name
req.http.HEADER:调用请求报文中http协议的指定的变量
req.request:请求方法

3. Vcl内置变量

太多了,现学现查:

官方连接:https://varnish-cache.org/docs/6.3/reference/vcl.html#varnish-configuration-language


三、配置与管理工具

$varnish_home/default.vcl:编写缓存策略的核心配置,通过官网学习最新的Varnish子进程的使用
$varnish_home/varnish.params:配置varnish服务启动时,进程的工作特性,例如监听的地址和端口,缓存机制;(注:自”5.0“版本开始,已经没有此参数文件,且官方给出的参考是可以从命令行设置启动的运行参数

1. varnish配置文件

涉及知识包括:vcl内置函数、常用变量、条件语句等,上文中已做一些基础入门。
需要深入学习请点击进阶传送门

2. 管理工具(more)

2.1 varnishd—启动命令

通过varnishd命令来启动varnish服务:

varnishd -a 0.0.0.0:80 -s malloc,10g -t 2592000 -w 200,4000,300 -h classic,300000 -p thread_pools=10 -p session_linger=100 -p listen_depth=4096 -p lru_interval=3600 -p sess_workspace=9437184 -p http_resp_size=4194304 -p thread_pool_workspace=9437184 -u admin -g admin -f /path/varnish.vcl

下面分析下上面主要的几个参数:

-a 0.0.0.0:80 #设置varnish监听本机80端口的请求
-s malloc,10g #分配10G的内存用于缓存
-t 2592000 #设置缓存对象过期时间为30天
-w 200,4000,300 #设置线程池中最小线程和最大线程数及线程空闲时间
-h classic,300000 #设置hash算法classic,bucket推荐为缓存对象数的10倍默认为16383,simple_list算法不推荐生产环境使用,critbit算法是一个几乎无锁的树
-p thread_pools=10 #设置线程池大小
-p session_linger=100 #让session重用的时间,重用session可提高性能,这个值设的太大如果没有重用就浪费资源,如果太小重用率太低(大家自己权衡设置)
-p listen_depth=4096 #监听队列的深度
-p sess_workspace=9437184 #session工作内存的大小,vcl操作中需要用到这些内存
-p http_resp_size=4194304 #后端请响应允许的最大字节数,这个的内存就是从上面的sess_workspace分配的
-p thread_pool_workspace=9437184 #设置线程池内存大小,vcl中处理请求和响应将用到
-u admin #以admin用户运行varnish服务
-g admin #以admin组运行varnish服务
-f /path/varnish.vcl #指定vcl配置

2.2 varnishstat—缓存信息统计

#显示指定参数的当前统计数据
varnishstat -1 -f MAIN.cache_hit -f MAIN.cache_miss 
#列出指定配置段的每个参数的意义
varnishstat -l -f MAIN -f MEMPOOL 

2.3 varnishtop—日志条目排名

-1:打印统计信息一次并退出,而不是持续更新的显示
-i taglist:可以同时使用多个-i选项,也可以一个选项跟上多个标签
-I <[taglist:]regex>:对指定的标签的值基于regex进行过滤
-x taglist:排除列表
-X <[taglist:]regex>:对指定的标签的值基于regex进行过滤,符合条件的予以排除

2.4 varnishadm—控制正在运行的Varnish实例

#登录管理程序
varnishadm -S /etc/varnish/secret -T 127.0.0.1:6082 

 
[sleepy↓]







 

转载于:https://www.cnblogs.com/sunhongleibibi/p/11613188.html