快取原本是乙個硬體的概念：快取就是資料交換的緩衝區（稱作cache），當某一硬體要讀取資料時，會首先從快取中查詢需要的資料，如果找到了則直接執行，找不到的話則從記憶體中找。由於快取的執行速度比記憶體快得多，故快取的作用就是幫助硬體更快地執行。
在乙個web應用中，應用到快取的地方有很多，主要有瀏覽器快取，頁面快取，伺服器快取，資料庫快取等。
快取的作用主要有：
瀏覽器端快取規則主要在http協議頭和html的meta標籤中定義。他們分別從新鮮度和校驗值兩個維度來規定瀏覽器是否可以直接使用快取中的副本，還是需要去源伺服器獲取更新的版本。
新鮮度（過期機制）：也就是快取副本有效期。乙個快取副本必須滿足以下條件，瀏覽器會認為它是有效的，足夠新的：
滿足以上兩個情況的一種，瀏覽器會直接從快取中獲取副本並渲染。
校驗值（驗證機制）：伺服器返回資源的時候有時在控制頭資訊帶上這個資源的實體標籤etag（entity tag），它可以用來作為瀏覽器再次請求過程的校驗標識。如過發現校驗標識不匹配，說明資源已經被修改或過期，瀏覽器需求重新獲取資源內容。
使用html meta 標籤，web開發者可以在html頁面的節點中加入標籤，**如下：
在http請求和響應的訊息報頭中，常見的與快取有關的訊息報頭有：
http快取機制
快取行為主要由快取策略決定，而快取策略由內容擁有者設定。這些策略主要通過特定的http頭部來清晰地表達。
當乙個使用者發起乙個靜態資源請求的時候，瀏覽器會通過以下幾步來獲取資源：
使用者操作行為與快取的關係
瀏覽器中的操作對快取的影響:
本地快取階段
expires
指定快取到期gmt的絕對時間，如果設了max-age，max-age就會覆蓋expires。如果expires到期需要重新請求。
cache-control
cache-control是http 1.1中為了彌補 expires 缺陷新加入的。對已快取的內容進行控制：
其他相關控制字段
用法舉例: cache-control: max-age=3600, must-revalidate
協商快取階段
last-modified & if-modified-since
last-modified與if-modified-since是一對報文頭，屬於http 1.0。
last-modified是web伺服器認為物件的最後修改時間，比如檔案的最後修改時間，動態頁面的最後產生時間。
etag & if-none-match
etag與if-none-match是一對報文，屬於http 1.1。
etag可以用來解決這種問題。etag是乙個檔案的唯一標誌符。就像乙個雜湊或者指紋，每個檔案都有乙個單獨的標誌，只要這個檔案發生了改變，這個標誌就會發生變化。
etag機制類似於樂觀鎖機制，如果請求報文的etag與伺服器的不一致，則表示該資源已經被修改過，需要發最新的內容給瀏覽器。
etag/lastmodified過程如下：
客戶端請求乙個頁面（a）。
伺服器返回頁面a，並在給a加上乙個last-modified/etag。
客戶端展現該頁面，並將頁面連同last-modified/etag一起快取。
客戶再次請求頁面a，並將上次請求時伺服器返回的last-modified/etag一起傳遞給伺服器。
伺服器檢查該last-modified或etag，並判斷出該頁面自上次客戶端請求之後還未被修改，直接返回響應304和乙個空的響應體。
304：通過if-modified-since if-match判斷資源是否修改，如未修改則返回304，發生了一次請求，但請求內容長度為0，節省了頻寬。 如果有多台負載均衡的伺服器，不同伺服器計算出的etag可能不同，這樣就會造成資源的重複載入。
etag 主要為了解決 last-modified 無法解決的一些問題：
1、一些檔案也許會週期性的更改，但是他的內容並不改變(僅僅改變的修改時間)，這個時候我們並不希望客戶端認為這個檔案被修改了，而重新get；
2、某些檔案修改非常頻繁，比如在秒以下的時間內進行修改，(比方說1s內修改了n次)，if-modified-since能檢查到的粒度是s級的，這種修改無法判斷(或者說unix記錄mtime只能精確到秒)；
3、某些伺服器不能精確的得到檔案的最後修改時間。
其他標籤
content-length：儘管並沒有在快取中明確涉及，content-length頭部在設定快取策略時很重要。某些軟體如果不提前獲知內容的大小以留出足夠空間，則會拒絕快取該內容。
vary：快取系統通常使用請求的主機和路徑作為儲存該資源的鍵。當判斷乙個請求是否是請求同樣內容時，vary頭部可以被用來提醒快取系統需要注意另乙個附加頭部。它通常被用來告訴快取系統同樣注意accept-encoding頭部，以便快取系統能夠區分壓縮和未壓縮的內容。
總結
瀏覽器第一次請求時:
瀏覽器再次請求時：
question: 設定了乙個月才過期的快取，如果伺服器端更新了css**，要怎麼讓使用者更新快取呢？
memcache的快取策略：(visio不能用了，自己畫的，略醜慎看)
資料庫的快取一般由資料庫提供，可以對錶建立快取記憶體。資料庫中，使用者可能多次執行相同的查詢語句，為了提高查詢效率，資料庫會在記憶體劃分乙個專門的區域，用來存放使用者最近執行的查詢，這塊區域就是快取。
資料庫快取的使用必須在一定的應用環境下：查詢的資料庫表不會經常變動、有大量相同的查詢(如訂單資訊查詢)。
ps：這個快取策略也可以用在前端，比如訂單資訊不變的情況下，可以在前端設定乙個物件，儲存請求的位址、引數、結果，第一次請求時會儲存請求的位址、引數和結果，再次請求時，如果請求的位址、引數一樣，則查詢該物件直接返回請求的結果。
快取的同步指的是寫命中快取的時候，如果保持快取與磁碟上資料一致性的問題。一般有兩種方案：
兩種方式各有利弊，直寫快取方法利用了快取記憶體中的資料始終與主儲存器中資料匹配的特點。但是，需要的匯流排週期卻非常耗時，從而降低效能。回寫快取可以維持效能，因為寫入始終是在「爆發」中進行的，因而執行所需的匯流排週期將大大減少。
兩個cpu，或者cpu與dma同時共享一塊物理記憶體時，writer在寫完後，要write back，這樣另乙個reader才能看到它寫入的資料；在writer變為reader的時候，需要invalidate，否則看不到另乙個 writer寫入的資料。所以在共享的時候，需要同時做writeback和invalidate。
最不經常使用演算法（lfu）：這個快取演算法使用乙個計數器來記錄條目被訪問的頻率。通過使用lfu快取演算法，最低訪問數的條目首先被移除。這個方法並不經常使用，因為它無法對乙個擁有最初高訪問率之後長時間沒有被訪問的條目快取負責。
最近最少使用演算法（lru）：這個快取演算法將最近使用的條目存放到靠近快取頂部的位置。當乙個新條目被訪問時，lru將它放置到快取的頂部。當快取達到極限時，較早之前訪問的條目將從快取底部開始被移除。這裡會使用到昂貴的演算法，而且它需要記錄「年齡位」來精確顯示條目是何時被訪問的。此外，當乙個lru快取演算法刪除某個條目後，「年齡位」將隨其他條目發生改變。
自適應快取替換演算法(arc)：在ibm almaden研究中心開發，這個快取演算法同時跟蹤記錄lfu和lru，以及驅逐快取條目，來獲得可用快取的最佳使用。
最近最常使用演算法（mru）：這個快取演算法最先移除最近最常使用的條目。乙個mru演算法擅長處理乙個條目越久，越容易被訪問的情況。
的預載入
**：
web快取技術
php本身沒有所謂處理快取的函式,因為快取實現的方式很多種.如檔案快取,那麼就是操作檔案的相關函式,如memcached,php也有相關的擴充套件函式支援.快取如何使用取決於你的程式快取方式和內容 ob 系列函式是處理向瀏覽器傳送資料的快取,跟資料快取是兩碼事 如果你不使用ob start 那麼你輸...
web快取技術
web快取包括瀏覽器快取，資料庫快取，伺服器快取。反向 伺服器，在資料 過程中，可以快取一些資料，以提高響應速度。這個了解的不多，不多寫了。我們可以將一些讀取非常頻繁的資料，比如訪問次數，表單中顯示的資料等，儲存在redis，memcached等基於記憶體的nosql資料庫中，作為快取，提高響應速度...
Web前後端的分離與耦合
關於前後端的定義，大體來說是這樣的 前後端的通訊一般通過http請求來實現 當然這裡也有個例外情況，比如有一部分功能可能要求實時性，像類似聊天類的功能，共享文件的功能，畫板分享的功能，多人協同操作的功能等等，需要通過socketio這樣的通訊機制進行。單一的程式框架模型會是mvc model vie...