Web缓存服务器：使用Varnish代替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的文章，已经是一篇可以完全替代Squid做网站缓存加速器的详细解决方案了。网上关于Varnish的资料很少，中文资料更是微乎其微，希望本文能够吸引更多的人研究、使用Varnish。

在我看来，使用Varnish代替Squid的理由有三点：
1、Varnish采用了“Visual Page Cache”技术，在内存的利用上，Varnish比Squid具有优势，它避免了Squid频繁在内存、磁盘中交换文件，性能要比Squid高。
2、Varnish的稳定性还不错，我管理的一台图片服务器运行Varnish已经有一个月，没有发生过故障，而进行相同工作的Squid服务器就倒过几次。
3、通过Varnish管理端口，可以使用正则表达式快速、批量地清除部分缓存，这一点是Squid不能具备的。

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中进行。

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程序去控制。

wget -c http://repo.varnish-cache. org/source/varnish-3.0.1.tar.gz

tar xzvf varnish-3.0.1.tar.gz

cd varnish-3.0.1

./configure --prefix=/usr/local/varnish

make

make install

groupadd varnish

useradd -d /var/lib/varnish -g varnish -s /sbin/nologin varnish

ln -s /usr/local/varnish/sbin/varnishd /usr/sbin/varnishd

启动varnish：

varnishd -f /usr/local/varnish/etc/varnish/default.vcl -s malloc,1G -g varnish -u varnish -T 127.0.0.1:2000

关闭varnish:

pkill varnish

启动参数介绍：

这个 –f 选项指定varnishd使用哪个配置文件。

这个 –s 选项用来确定varnish使用的存储类型和存储容量，我使用的是malloc类型（malloc是一个C函数，用于分配内存空间）， 1G 定义多少内存被malloced，1G = 1gigabyte。

Varnish有一个基于文本的管理接口，启动它的话可以在不停止varnish的情况下来管理varnish。您可以指定管理软件监听哪个接口。当然您不能让全世界的人都能访问您的 varnish管理接口，因为他们可以很轻松的通过访问varnish管理接口来获得您的root访问权限。我推荐只让它监听本机端口。如果您的系统里有您不完全信任的用户，您可以通过防火墙规则来限制他访问varnish的管理端口。

这一句的意思是制定varnish监听所有IP发给8080端口的http请求，如果在生产环境下，您应该让varnish监听80，这也是默认的。

vcl配置文件的介绍请执行如何命令查看：

man /usr/local/varnish/share/man/man7/vcl.7

2011年08月24日，Varnish 3.0.1 RC1 发布，HTTP加速器。^[2]　

2011年08月30日，Varnish 3.0.1 正式版发布了，与 3.0 版本比较，改进包括：

对象以优雅和保持设置被错误地视为候选的短暂存储,但不会迅速清理,这表现为如果有一个内存泄漏。现在这是固定的。

当多个客户正在等待一个对象,所有客户端会醒来当一个物体变得可用,从而导致卡线程。这已经被修正

一个bug在XML实体是如何处理应急服务国际公司已经固定

文档目睹了大量的更新