乙個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=***:***:***。
那麼構成目錄名字的字元哪來的呢？假設我們的儲存目錄為/cache，levels=1:2，那麼對於上面的檔案 就是這樣儲存的：
/cache/0/8d/8ef9229f02c5672c747dc7a324d658d
0
看到0和8d這兩個目錄名怎麼來的了吧，不用解釋了。
物件建立完成之後，就需要快取物件管理結構中去了，這個ngx_http_file_cache_exists去處理的。
如果在建立這個檔案時，當前目錄及檔案已經存在，那如何處理？大家可以去翻翻**，看nginx怎麼處理的。
討論先告乙個段落，其實現在都是一些準備工作，下次討論後端內容到來的處理。
伺服器快取
快取可以在客戶端和伺服器中做，要是之間還有 也可能對響應進行快取。是將客戶端和伺服器連線在一起，作為中間人角色，可以將客戶端請求響應的內容進行快取，在下次客戶端快取時，直接返回快取結果，提高效能。快取控制是在http頭資訊中cache control設定，當設成private時，不會進行快取，當設定...
快取伺服器
nosql nosql not only sql 意即 不僅僅是sql 泛指非關係型的資料庫,隨著網際網路web2.0 的興起，傳統的關聯式資料庫在應付web2.0 特別是超大規模和高併發的sns型別的web2.0純動態 已經顯得力不從心，暴露了很多難以克服的問題，而非關係型的資料庫則由於其本身的特...
memcached 快取伺服器
memcached 是高效能的 分布式記憶體快取伺服器。一般的使用目的是，通過快取資料庫查詢結果，減少資料庫訪問次數，以提高動態web應用的速度 提高可擴充套件性。主要特點 1 c s架構，協議簡單 2 基於libevent的事件處理 epoll 3 slab allocation記憶體管理機制 4...