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

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

一個(gè)重要的概念

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

CDN緩存策略

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