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實體是如何處理應急服務國際公司已經固定

文檔目睹了大量的更新