概况

Varnish文件缓存的工作流程

Varnish介绍

varnish 总体架构

概况

Varnish是一款高性能的开源HTTP加速器，挪威最大的在线报纸 Verdens Gang 使用3台Varnish代替了原来的12台Squid，性能比以前更好。

Varnish 的作者Poul-Henning Kamp是FreeBSD的内核开发者之一，他认为现在的计算机比起1975年已经复杂许多。在1975年时，储存媒介只有两种：内存与硬盘。但现在计算机系统的内存除了主存外，还包括了CPU内的L1、L2，甚至有L3快取。硬盘上也有自己的快取装置，因此Squid Cache自行处理物件替换的架构不可能得知这些情况而做到最佳化，但操作系统可以得知这些情况，所以这部份的工作应该交给操作系统处理，这就是 Varnish cache设计架构。

varnish项目是2006年发布的第一个版本0.9.距今已经四年多了，此文档之前也提过varnish还不稳定，那是2007年时候编写的，经过varnish开发团队和网友们的辛苦耕耘，现在的varnish已经很健壮。很多门户网站已经部署了varnish，并且反应都很好，甚至反应比squid还稳定，且效率更高，资源占用更少。相信在反向代理，web加速方面，varnish已经有足够能力代替squid。

Varnish文件缓存的工作流程

Varnish与一般服务器软件类似，分为master（management）进程和child（worker，主要做cache的工作）进程。master进程读入命令，进行一些初始化，然后fork并监控child进程。child进程分配若干线程进行工作，主要包括一些管理线程和很多woker线程。

针对文件缓存部分，master读入存储配置（-s file[,path[,size[,granularity]]] ），调用合适的存储类型，然后创建/读入相应大小的缓存大文件。接着，master初始化管理该存储空间的结构体。这些变量都是全局变量，在fork以后会被child进程所继承（包括文件描述符）。

在child进程主线程初始化过程中，将前面打开的存储大文件整个mmap到内存中（如果超出系统的虚拟内存，mmap失败，进程会减少原来的配置mmap大小，然后继续mmap），此时创建并初始化空闲存储结构体，挂到存储管理结构体，以待分配。

接着，真正的工作开始，Varnish的某个负责接受新HTTP连接的线程开始等待用户，如果有新的HTTP连接过来，它总负责接收，然后叫醒某个等待中的线程，并把具体的处理过程交给它。Worker线程读入HTTP请求的URI，查找已有的object，如果命中则直接返回并回复用户。如果没有命中，则需要将所请求的内容，从后端服务器中取过来，存到缓存中，然后再回复。

分配缓存的过程是这样的：它根据所读到object的大小，创建相应大小的缓存文件。为了读写方便，程序会把每个object的大小变为最接近其大小的内存页面倍数。然后从现有的空闲存储结构体中查找，找到最合适的大小的空闲存储块，分配给它。如果空闲块没有用完，就把多余的内存另外组成一个空闲存储块，挂到管理结构体上。如果缓存已满，就根据LRU机制，把最旧的object释放掉。

释放缓存的过程是这样的：有一个超时线程，检测缓存中所有object的生存期，如果超初设定的TTL（Time To Live）没有被访问，就删除之，并且释放相应的结构体及存储内存。注意释放时会检查该存储内存块前面或后面的空闲内存块，如果前面或后面的空闲内存和该释放内存是连续的，就将它们合并成更大一块内存。

整个文件缓存的管理，没有考虑文件与内存的关系，实际上是将所有的object都考虑是在内存中，如果系统内存不足，系统会自动将其换到swap空间，而不需要varnish程序去控制。

Varnish介绍

1 Varnish is HTTP accelerator.

2 Varnish stores data in virtual memory and leaves the task of deciding what is stored in memory

and what gets paged out to disk to the operating system

3 The Varnish web site claims that Varnish is ten to twenty times faster than the popular Squid

cache on the same hardware.

4 Varnish is heavily threaded

varnish 总体架构

2.1 总体流程

主进程 fork 子进程，主进程等待子进程的信号，子进程退出后，主进程重新启动子进程

子进程生成若干线程。

Accept 线程：接受请求，将请求挂在 overflow对列上

Work 线程： 多个，从对列上摘除请求，对请求进行处理，直到完成，然后处理下一个

请求

Epoll 线程： 一个请求处理称作一个 session，在 session 周期内，处理完请求后，会交给

Epoll 处理，监听是否还有事件发生。

Expire 线程：对于缓存的对象，根据过期时间，组织成二叉堆，该线程周期检查该堆的

根，处理过期的文件。

线程之间的关系：

2.1.1 accept 线程

监听端口，接受连接。

接受后组织成 struct ses（session 结构） ，看是否有空闲的工作线程，如果有，将请求给它，

pthread_cond_signal 信号通知它没有空闲线程，如果 overflow过大，则放弃该请求。否则，

将其挂在 overflow 上（需要更多工作线程，发通知）。

继续监听 2.1.2 work 线程

从 overflow队列上摘取请求（struct ses），进入状态机处理，处理结束后，通过 pipe通信，

将 struct ses发送给 epoll 线程。

2.1.3 Epoll 线程,得到传过来的 struct ses，若还没有过期，将 socket 放入 epoll 的事件中，事

件发生时，也会将其放入到 overflow中进行。