大型web應用緩存必不可少，本文我們講了前端本地緩存，服務器端緩存，HTTP緩存機制，CDN緩存，html5離線存儲等緩存策略。

緩存策略
　　瀏覽器端的緩存規(guī)則
　　對于瀏覽器端的緩存來講，這些規(guī)則是在HTTP協(xié)議頭和HTML頁面的Meta標簽中定義的。他們分別從新鮮度和校驗值兩個維度來規(guī)定瀏覽器是否可以直接使用緩存中的副本，還是需要去源服務器獲取更新的版本。
　　新鮮度（過期機制）：也就是緩存副本有效期。一個緩存副本必須滿足以下條件，瀏覽器會認為它是有效的，足夠新的：
　　 含有完整的過期時間控制頭信息（HTTP協(xié)議報頭），并且仍在有效期內；
　　 瀏覽器已經使用過這個緩存副本，并且在一個會話中已經檢查過新鮮度
　　滿足以上兩個情況的一種，瀏覽器會直接從緩存中獲取副本并渲染。
　　校驗值（驗證機制）：服務器返回資源的時候有時在控制頭信息帶上這個資源的實體標簽Etag（Entity Tag），它可以用來作為瀏覽器再次請求過程的校驗標識。如過發(fā)現(xiàn)校驗標識不匹配，說明資源已經被修改或過期，瀏覽器需求重新獲取資源內容。

一個重要的概念

緩存命中率：一個緩存的有效性是依照緩存的命中率來度量。它是根據得到數(shù)據請求次數(shù)與所有請求次數(shù)的比率。緩存命中率高意味著有很高的比率數(shù)據是從緩存中獲取到數(shù)據的。
　　Web緩存的作用
　　減少網絡帶寬消耗
　　 降低服務器壓力
　　減少網絡延遲，加快頁面打開速度
　　HTTP緩存機制
　　緩存行為主要由緩存策略決定，而緩存策略由內容擁有者設置。這些策略主要通過特定的HTTP頭部來清晰地表達。
　　當一個用戶發(fā)起一個靜態(tài)資源請求的時候，瀏覽器會通過以下幾步來獲取資源：
　　 本地緩存階段：先在本地查找該資源，如果有發(fā)現(xiàn)該資源，而且該資源還沒有過期，就使用這一個資源，完全不會發(fā)送http請求到服務器；
　　協(xié)商緩存階段：如果在本地緩存找到對應的資源，但是不知道該資源是否過期或者已經過期，則發(fā)一個http請求到服務器,然后服務器判斷這個請求，如果請求的資源在服務器上沒有改動過，則返回304，讓瀏覽器使用本地找到的那個資源；
 　　緩存失敗階段：當服務器發(fā)現(xiàn)請求的資源已經修改過，或者這是一個新的請求(在本來沒有找到資源)，服務器則返回該資源的數(shù)據，并且返回200， 當然這個是指找到資源的情況下，如果服務器上沒有這個資源，則返回404。
用戶操作行為與緩存
　　瀏覽器中的操作對緩存的影響:
 　　強制刷新 ? 當按下ctrl+F5來刷新頁面的時候, 瀏覽器將繞過各種緩存(本地緩存和協(xié)商緩存), 直接讓服務器返回最新的資源;
　　普通刷新 ? 當按下F5來刷新頁面的時候,瀏覽器將繞過本地緩蹲來發(fā)送請求到服務器, 此時, 協(xié)商緩存是有效的
　　 回車或轉向 ? 當在地址欄上輸入回車或者按下跳轉按鈕的時候, 所有緩存都生效
　　本地緩存階段
　　Expires
　　指定緩存到期GMT的絕對時間，如果設了max-age，max-age就會覆蓋expires。如果expires到期需要重新請求。
　　Cache-Control
　　Cache-Control:這個是http 1.1中為了彌補 Expires 缺陷新加入的。
　　對已緩存的內容進行控制：
　　Cache-control: public表示緩存的版本可以被代理服務器或者其他中間服務器識別。
　　Cache-control: private意味著這個文件對不同的用戶是不同的。只有用戶自己的瀏覽器能夠進行緩存，公共的代理服務器不允許緩存。
　　Cache-control: no-cache意味著文件的內容不應當被緩存。這在搜索或者翻頁結果中非常有用，因為同樣的URL，對應的內容會發(fā)生變化。
　　其他相關控制字段：
　　max-age: 指定緩存過期的相對時間秒數(shù)，max-ag=0或者是負值，瀏覽器會在對應的緩存中把Expires設置為1970-01-01 08:00:00 。
　　s-maxage: 類似于max-age，只用在共享緩存上，比如proxy.
　　public: 通常情況下需要http身份驗證的情況，響應是不可cahce的，加上public可以使它被cache。
　　no-cache: 強制瀏覽器在使用cache拷貝之前先提交一個http請求到源服務器進行確認。這對身份驗證來說是非常有用的,能比較好的遵守 (可以結合public進行考慮)。它對維持一個資源總是最新的也很有用，與此同時還不完全喪失cache帶來的好處)，因為它在本地是有拷貝的，但是在用之前都進行了確認，這樣http請求并未減少，但可能會減少一個響應體。
　　no-store: 告訴瀏覽器在任何情況下都不要進行cache，不在本地保留拷貝。
　　must-revalidate: 強制瀏覽器嚴格遵守你設置的cache規(guī)則。
　　proxy-revalidate: 強制proxy嚴格遵守你設置的cache規(guī)則。
　　用法舉例: Cache-Control: max-age=3600, must-revalidate
　　cache:使用本地緩存，不發(fā)生請求。
　　協(xié)商緩存階段
　　Last-Modified & if-modified-since
　　Last-Modified與If-Modified-Since是一對報文頭，屬于http 1.0。
　　last-modified是WEB服務器認為對象的最后修改時間，比如文件的最后修改時間，動態(tài)頁面的最后產生時間。
　　ETag & If-None-Match
　　ETag與If-None-Match是一對報文，屬于http 1.1。
　　ETag可以用來解決這種問題。ETag是一個文件的唯一標志符。就像一個哈希或者指紋，每個文件都有一個單獨的標志，只要這個文件發(fā)生了改變，這個標志就會發(fā)生變化。
　　ETag機制類似于樂觀鎖機制，如果請求報文的ETag與服務器的不一致，則表示該資源已經被修改過來，需要發(fā)最新的內容給瀏覽器。
　　同時使用這兩個報文頭，在完全匹配If-Modified-Since和If-None-Match即檢查完修改時間和Etag之后，如都與服務器的相符，服務器返回304，否則，發(fā)送最新內容給瀏覽器。
　　Etag/lastModified過程如下：
　　1.客戶端請求一個頁面（A）。
　　2.服務器返回頁面A，并在給A加上一個Last-Modified/ETag。
　　3.客戶端展現(xiàn)該頁面，并將頁面連同Last-Modified/ETag一起緩存。
　　4.客戶再次請求頁面A，并將上次請求時服務器返回的Last-Modified/ETag一起傳遞給服務器。
　　5.服務器檢查該Last-Modified或ETag，并判斷出該頁面自上次客戶端請求之后還未被修改，直接返回響應304和一個空的響應體。
　　 304：通過If-Modified-Since If-Match判斷資源是否修改，如未修改則返回304，發(fā)生了一次請求，但請求內容長度為0，節(jié)省了帶寬。 如果有多臺負載均衡的服務器，不同服務器計算出的Etag可能不同，這樣就會造成資源的重復加載。
　　Etag 主要為了解決 Last-Modified 無法解決的一些問題：
　　1、一些文件也許會周期性的更改，但是他的內容并不改變(僅僅改變的修改時間)，這個時候我們并不希望客戶端認為這個文件被修改了，而重新GET；
　2、某些文件修改非常頻繁，比如在秒以下的時間內進行修改，(比方說1s內修改了N次)，If-Modified-Since能檢查到的粒度是s級的，這種修改無法判斷(或者說UNIX記錄MTIME只能精確到秒)；
　　3、某些服務器不能精確的得到文件的最后修改時間。
　　其他標簽
　　Content-Length：盡管并沒有在緩存中明確涉及，Content-Length頭部在設置緩存策略時很重要。某些軟件如果不提前獲知內容的大小以留出足夠空間，則會拒絕緩存該內容。
　　Vary：緩存系統(tǒng)通常使用請求的主機和路徑作為存儲該資源的鍵。當判斷一個請求是否是請求同樣內容時，Vary頭部可以被用來提醒緩存系統(tǒng)需要注意另一個附加頭部。它通常被用來告訴緩存系統(tǒng)同樣注意Accept-Encoding頭部，以便緩存系統(tǒng)能夠區(qū)分壓縮和未壓縮的內容。
　　服務器端緩存
　　CDN緩存
　　CDN緩存，也叫網關緩存、反向代理緩存。瀏覽器先向CDN網關發(fā)起WEB請求，網關服務器后面對應著一臺或多臺負載均衡源服務器，會根據它們的負載請求，動態(tài)地請求轉發(fā)到合適的源服務器上。

CDN緩存策略

CDN邊緣節(jié)點緩存策略因服務商不同而不同，但一般都會遵循h(huán)ttp標準協(xié)議，通過http響應頭中的Cache-control: max-age的字段來設置CDN邊緣節(jié)點數(shù)據緩存時間。
　　當客戶端向CDN節(jié)點請求數(shù)據時，CDN節(jié)點會判斷緩存數(shù)據是否過期，若緩存數(shù)據并沒有過期，則直接將緩存數(shù)據返回給客戶端；否則，CDN節(jié)點就會向源站發(fā)出回源請求（back to the sourcerequest），從源站拉取最新數(shù)據，更新本地緩存，并將最新數(shù)據返回給客戶端。
　　CDN服務商一般會提供基于文件后綴、目錄多個維度來指定CDN緩存時間，為用戶提供更精細化的緩存管理。
CDN緩存時間會對“回源率”產生直接的影響。若CDN緩存時間較短，CDN邊緣節(jié)點上的數(shù)據會經常失效，導致頻繁回源，增加了源站的負載，同時也增大的訪問延時；若CDN緩存時間太長，會帶來數(shù)據更新時間慢的問題。開發(fā)者需要增對特定的業(yè)務，來做特定的數(shù)據緩存時間管理。
　　CDN緩存刷新CDN邊緣節(jié)點對開發(fā)者是透明的，相比于瀏覽器Ctrl+F5的強制刷新來使瀏覽器本地緩存失效，開發(fā)者可以通過CDN服務商提供的“刷新緩存”接口來達到清理CDN邊緣節(jié)點緩存的目的。這樣開發(fā)者在更新數(shù)據后，可以使用“刷新緩存”功能來強制CDN節(jié)點上的數(shù)據緩存過期，保證客戶端在訪問時，拉取到最新的數(shù)據。
　　CDN的優(yōu)勢
　　 CDN節(jié)點解決了跨運營商和跨地域訪問的問題，訪問延時大大降低；
　　大部分請求在CDN邊緣節(jié)點完成，CDN起到了分流作用，減輕了源站的負載。
　　CDN緩存的缺點
　　當網站更新時，如果CDN節(jié)點上數(shù)據沒有及時更新，即便用戶再瀏覽器使用Ctrl +F5的方式使瀏覽器端的緩存失效，也會因為CDN邊緣節(jié)點沒有同步最新數(shù)據而導致用戶訪問異常。
　　Combo服務
　　Combo服務，也就是我們在最終拼接生成頁面資源引用的時候，并不是生成多個獨立的link標簽，而是將資源地址拼接成一個url路徑，請求一種線上的動態(tài)資源合并服務，從而實現(xiàn)減少HTTP請求的需求。
　　/??fle1,file2,file3,...的url請求響應就是動態(tài)combo服務提供的，它的原理很簡單，就是根據url找到對應的多個文件，合并成一個文件來響應請求，并將其緩存，以加快訪問速度。
　　但它也存在一些缺陷：
　　瀏覽器有url長度限制，因此不能無限制的合并資源。
　　如果用戶在網站內有公共資源的兩個頁面間跳轉訪問，由于兩個頁面的combo的url不一樣導致用戶不能利用瀏覽器緩存來加快對公共資源的訪問速度。如果combo的url中任何一個文件發(fā)生改變，都會導致整個url緩存失效，從而導致瀏覽器緩存利用率降低。
　　HTML5緩存思路
　　HTML5離線應用緩存manifest
　　用戶可離線訪問你的應用，這對于無法隨時保持聯(lián)網狀態(tài)的移動終端用戶來說尤其重要
　　 用戶訪問本地的緩存文件，通常意味著更快的訪問速度
　　僅僅加載被修改過的資源，避免同一資源對服務器多次的請求，大大降低了對服務器的訪問壓力manifest文件羅列了需要被緩存的文件清單。