nginx的cache系統設計原理

這裡我們nginx的cache系統為線索，來探討一個快取伺服器的設計和相關細節，我盡量站在設計和框架的角度來分析，限於篇幅這裡不再去擼代碼了，相關的細節，歡迎大家一起參與討論。

    一個cache伺服器中從後端取得文件之後，要么直接發送給客戶端(學名叫透傳)，要么緩存在本地，後續相同的請求訪問到cache伺服器時，就可以直接拿本地的拷貝來用了，如果可以用的話。如果本地快取的檔案被後續的請求存取到，在cache中叫做命中(即Hit)。如果本地還沒有文件的快取拷貝，那麼cache伺服器需要根據配置或者做解析域名，去後端獲取文件，這時稱為緩存miss，即未命中。關於cache伺服器更多的知識，我們在分析nginx的快取系統時再深入討論。

    nginx的儲存系統分成兩類，一類是透過proxy_store開啟的，儲存方式是依照url中的檔案路徑，儲存在本機。例如/file/2013/0001/en/test.html，那麼nginx就會在指定的儲存目錄下依序建立各個目錄和檔案。另一類是透過proxy_cache開啟，這種方式儲存的檔案不是按照url路徑來組織的，而是使用一些特殊方式來管理的(這裡稱為自訂方式)，自訂方式就是我們要重點分析的。那麼這兩種方式各有什麼優點呢？

    依url路徑儲存檔案的方式，程式處理起來比較簡單，但是效能不行。首先有的url巨長，我們要在本機檔案系統上建立如此深的目錄，那麼檔案的開啟和查找都很慢(回想kernel中透過路徑名查找inode的過程吧)。如果使用自訂方式來處理模式，儘管也離不開檔案和路徑，但是它不會因url長度而產生複雜性增加和效能的降低。從某種意義上來說這是一種用戶態檔案系統，最典型的應該算是squid中的CFS。 nginx使用的方式相對簡單，主要靠url的md5值來管理，後面我們會分析。

    快取離不開從後端取內容，然後傳送給客戶端。具體的處理方式大家很容易就會想到，一定是一邊接收一邊發送，其他的方式都太低效了，如讀完再發等等。這裡提一下nginx邊收邊發，使用的結構是ngx_event_pipe_t，它是溝通後端和客戶端的媒介。由於該結構是一個通用組件，所以需要一些特殊的標記來處理涉及存儲的相關功能，那麼成員cacheable就擔當了這份重任。

p->cacheable = u->cacheable || u->store;

即cacheable為1，則需要存儲，否則不存儲。那u->cacheable跟u->store代表什麼？他們分別代表前面說的兩種方式，即proxy_cache和proxy_store。

(補充一些知識，nginx在取後端資料時，它的行為受proxy_buffering控制，作用是為後端的伺服器啟用應答緩衝。如果啟用緩衝，nginx假設被代理伺服器能夠非常快的傳遞應答，並將其放入緩衝區，可以使用proxy_buffer_size和proxy_buffers設定相關參數。

    這裡都是一些擦邊球，我們還沒有接觸nginx cache功能的核心。從實作上看，在nginx upstream結構中有個成員叫cache，它的型別是ngx_shm_zone_t。如果我們開啟cache功能，cache成員用來管理共享記憶體(為什麼用到了共享記憶體？)，而其他方式的儲存該成員都為NULL。另外有一點要說明一下，在cache系統中一個檔案通常稱為store object，也就是快取對象，所以在進行cache之前必然需要先建立一個store object。一個重要的問題就是如何選擇創作的時機，這點大家有什麼看法？首先我們要檢查一個檔案是否需要緩存，很明顯GET方法請求的檔案一般需要緩存，所以我們在請求處理的前期，看到了GET方法，就可以先建立一個物件。但是很多時候，即使是一個GET方法請求的文件也不能緩存，那麼你過早的創建對象，不僅浪費時間也浪費了空間，到頭來還要將它銷毀。那麼什麼會影響GET請求的儲存呢？那就是回應頭中的Cache-control字段，這個字段就告訴代理或瀏覽器，該文件能否被快取。一般的cache伺服器面對回應頭中沒有Cache-control欄位的請求，預設都是要快取的。

    基於這一點的考慮，我們開發的cache伺服器就是在回應頭解析完成，拿到可快取的足夠證據之後，才會建立快取物件。遺憾的是，nginx沒有這麼做。

nginx在ngx_http_upstream_init_request函數中完成快取物件的創建，這個函數處在http處理的什麼階段呢？在跟後端建立連線之前。這個地方，我個人認為不太適合。 。 。大家認為呢？

    關於創建過程，大家可以去讀函數ngx_http_upstream_cache。這裡我拿我們的cache跟nginx比較來分析吧。在我們的request中使用一個名叫store的成員，來跟快取物件建立連結。 nginx也差不多，它的request結構體中有個cache成員來做同樣的事情。差別在於我們的store成員對應的空間在共享記憶體中，而nginx則是在r->pool裡申請的(我們為什麼這麼做？)。

    下一步，nginx需要依照設定來產生快取物件的key，這裡一般都是用md5來算的。這個key作為一個快取物件在系統中的唯一標識，很多人可能擔心md5碰撞的問題。這個我認為要求如果不是特別苛刻，這裡完全可以接受的，而且處理也相對簡單。

後面要處理的是，檔案到底應該已怎樣的形式儲存在磁碟？

    我們拿前面用過的例子：/file/2013/0001/en/test.html，它對應的md5值是8ef9229f02c5672c747dc7a324d658d0，實際上nginx就用它當做檔案名稱。這樣就可以了？如果我們找一個目錄來存放文件，裡面都是一堆這樣的文件，那會怎麼樣呢？我們知道，大多數檔案系統下，都對單一目錄下的檔案數量有限制，所以這樣簡單粗暴的處理是不行的。那怎麼辦？ nginx透過設定可以讓你使用多層目錄，來解決這個問題。簡單來說，nginx透過levels這個指令指定目錄層數(冒號分隔)和每個目錄名字的字元數，在我們的例子中，假設配置levels=1:2，意思是說使用兩級目錄，第一級目錄名是一個字符，第二級用兩個字符。但是nginx最大支援3級目錄，即levels=xxx:xxx:xxx。

    那麼構成目錄名字的字符哪來的呢？ 假設我們的儲存目錄為/cache，levels=1:2，那麼對於上面的檔案就是這樣儲存的：

  /cache/0/8d/8ef9229f02567296072329     看到0和8d這兩個目錄名怎麼來的了吧，不用解釋了。

    物件建立完成之後，需要快取物件管理結構中去了，這個去處理的去處理程序。

    如果在建立此檔案時，目前目錄及檔案已經存在，那麼該如何處理？大家可以去翻程式碼，看nginx怎麼處理的。

    討論先告一個段落，其實現在都是一些準備工作，下次討論後端內容到來的處理。

    延伸閱讀：

    http://www.pagefault.info/?p=123?com 以上就介紹了nginx的cache系統設計原理，包括了方面的內容，希望對PHP教程有興趣的朋友有幫助。