Final
Docker
keepalived
sonarqube
Varnish
Openstack基础配置
varnish基础配置
vcl –> vcl compiler –> c compiler
简单处理逻辑
客户端请求报文 –> 判断URL是否是可缓存项 –> 不是可缓存项 –> 去后端服务取数据并返回给用户
若是可缓存项 –> 判断哈希值 –> 没有被命中 –> 去后端服务取数据并返回给用户
若缓存被命中 –> 缓存服务器直接返回给用户
varnish状态引擎
以上是varnish4.0 的状态引擎图，每个状态引擎彼此的关系，以及 varnish 内部缓存处理逻辑
删除缓存vcl\_purge –> vcl\_synth返回删除操作结果
vcl\_pipe表示如果通过 vcl\_hash 处理后发现用户请求的方法不识别，这个时候会将请求报文交给 vcl\_pipe 处理；
waiting表示等待，服务器负载已经上限了
到本地的第一步，根据本地的缓存策略，判断是不是要查询缓存
如果http 和https都开启的情况下，不建议开启协议哈希，内容一样，导致会有http和https数据各一份
默认本质上都是四层代理，简单来说七层是四层的一种特殊形式，其实vcl\_pipe就是引用这种机制
请求到四层，四层识别是HTTP协议，则转给本地七层代理处理，在七层更为强大的处理逻辑
若不是HTTP协议，则转发给后端其他服务
PRE 是HTTP版本2引入的方法， varnish版本4还不支持
状态阶段
第一阶段：
vcl\_recv # 接受客户端请求，进行判断
第二阶段：
vcl\_hash # 进行 hash 计算，不进行判读处理，计算之后送往各个第三阶段状态引擎中
第三阶段：
vcl\_hit # 缓存命中，到此处理
vcl\_pass # 缓存跳过
vcl\_miss # 缓存未命中
vcl\_purge # 清理缓存
vcl\_pipe #对于无法识别的 http 首部请求直接送入管道，交由后端处理不再处理
第四阶段：
vcl\_deliver: 大部分响应客户端的请求由此发送回去
vcl\_synth: 接受来自 vcl\_purge 的任务，对于指定的缓存，进行删除处理
后端状态分为两阶段：
第一阶段：
vcl\_backend\_fetch：接受来自前端状态 vcl\_pass 或 vcl\_miss 的任务，向后端主机发送请求
第二阶段：
vcl\_backend\_response：接受到后端返回正常状态报文，进行是否缓存检查，需要缓存的响应将其缓存，不需要则不缓存，最后送到 vcl\_deliver
vcl\_backend\_error：后端主机错误，返回错误响应
除此之外还有两个特殊状态引擎：
vcl\_init：在处理任何请求之前要执行的 vcl 代码：主要用于初始化 VMODs；
vcl\_fini：所有的请求都已经结束，在 vcl 配置被丢弃时调用；主要用于清理 VMODs；
实例1，真实的缓存代理
用户 –> varnish –> docker
准备后端服务docker
测试本地访问容器
修改varnish配置文件，后端IP及端口项
重载varnish
注意不要重启varnish服务，使用重载varnish\_reload\_vcl
客户端测试访问
可使用交互式命令，默认是服务端操作，端口也只有本地开放，有交互和非交互式
vcl开头都是于vcl管理相关的
使用交互式
实例2，在http头部信息添加缓存标志及命中次数（修改回报报文）
在varnish代理端角度来看
客户端发过来的报文，不能修改
发给后端的请求报文，可修改
后端服务回报，不能修改
回报给客户端的报文，可修改，此处实例改这里http头部信息
修改varnish配置文件
使用varnish客户端交互模式手工reload
客户端测试访问
实例3，根据请求的URL（目录路径path）来判断是否需要缓存
修改varnish配置文件
客户端访问多次login目录未被缓存，访问其他目录则被缓存
转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 438803792@qq.com
Loading...