一談緩存，內(nèi)心頓時(shí)豁然開朗。迫于key-value的形式，總感覺輕風(fēng)拂面，楊柳依依，一切都盡在我掌握之中。猶如那一眼相中佳人的沖動(dòng)，腦子里盡是佳人的容顏。
那緩存如果站在網(wǎng)站架構(gòu)的角度，你知道它的設(shè)計(jì)原理和影響作用嗎？
絮叨
在商業(yè)的世界里，常說的一句話是 "現(xiàn)金為王"。在互聯(lián)網(wǎng)、移動(dòng)互聯(lián)網(wǎng)乃至整個(gè)軟件技術(shù)的世界里面，與之相近的就是 "緩存為王"。
為何這么說呢？
試想一下，你個(gè)完整的網(wǎng)絡(luò)請(qǐng)求（HTTP、SOAP、RPC等），如果在執(zhí)行過程的某個(gè)部分尚有緩存，是不是就能提前響應(yīng)給客戶端呢？
為何現(xiàn)在很多中大型公司在面試時(shí)，對(duì)緩存的應(yīng)用、原理、高可用等一系列問題，都一撲啦的扔給你，讓你難以招架。原因都在這。
什么是緩存？
緩存：存儲(chǔ)在計(jì)算機(jī)上的一個(gè)原始數(shù)據(jù)復(fù)制，以便于訪問
--維基百科
緩存是系統(tǒng)快速響應(yīng)中的一種關(guān)鍵技術(shù)，是一組被保存起來以備將來使用的東西。介于應(yīng)用開發(fā)和系統(tǒng)開發(fā)之間，是產(chǎn)品經(jīng)理經(jīng)常顧及不到的地方，也是技術(shù)架構(gòu)設(shè)計(jì)中的非功能性約束。
應(yīng)用開發(fā)我知道，這系統(tǒng)緩存是個(gè)什么情況呀，小吒哥？
不要著急，往后面看
什么是多級(jí)緩存架構(gòu)？
顧名思義，由多個(gè)維度共同組成的緩存工程。因?yàn)榫彺嬖诓煌膱鼍坝兄煌囊饬x。采用的技術(shù)手段也不同。
按緩存存在形式分：
- 硬件緩存（如CPU、硬盤等）
- 操作系統(tǒng)緩存
- 軟件緩存 系統(tǒng)緩存是什么？
操作系統(tǒng)是管理計(jì)算機(jī)硬件與軟件資源的計(jì)算機(jī)程序，而硬、軟件件運(yùn)行速度的快慢基本由緩存決定，緩存的容量越大，相應(yīng)的硬件運(yùn)行速度也就越快。所以系統(tǒng)緩存就是操作系統(tǒng)調(diào)用硬件資源（內(nèi)存、文件等）和調(diào)用應(yīng)用程序時(shí)，能夠啟動(dòng)加速執(zhí)行的作用。
總結(jié)：操作系統(tǒng)存調(diào)用涉及到有緩存的部分，都可算系統(tǒng)緩存
軟件運(yùn)行都需建立在操作系統(tǒng)之上，在運(yùn)行時(shí)需要把程序裝載到內(nèi)存中，但軟件執(zhí)行操作內(nèi)存時(shí)都是基于虛擬內(nèi)存映射的機(jī)制，并不是直接操作物理內(nèi)存。虛擬內(nèi)存以塊表（內(nèi)存塊組成的表格）的形式來存儲(chǔ)相關(guān)資源。
注：物理內(nèi)存組成上由多個(gè)方塊狀的元素構(gòu)成,該元素是內(nèi)存管理的最小單位。每一個(gè)元素有8個(gè)小電容,存儲(chǔ)8個(gè)bit,即1字節(jié)。
是不是和磁盤塊差不多， ^_^ 。吒吒輝懂你呀
為提高系統(tǒng)的存取速度，在 地址映射機(jī)制中增加了一個(gè)小容量的聯(lián)想寄存器，即塊表。
內(nèi)存塊表
它 用來存放當(dāng)前訪問最頻繁的少數(shù)活動(dòng)頁面的頁數(shù)。當(dāng)某用戶需存取數(shù)據(jù)時(shí)，根據(jù)數(shù)據(jù)所在的邏輯頁號(hào)在塊表中找到對(duì)應(yīng)的內(nèi)存塊號(hào)，再聯(lián)系其頁內(nèi)地址，形成物理地址。
總結(jié)：讀取數(shù)據(jù)時(shí)-->先找邏輯頁--->排查內(nèi)存塊號(hào)--->獲得物理層內(nèi)存表示頁內(nèi)地址---->物理地址
如果塊表中沒有相應(yīng)的邏輯頁號(hào)，則地址映射仍然可以通過內(nèi)存中的頁表進(jìn)行操作，只是它得到是空閑塊號(hào)，必須將該塊號(hào)填入塊表中的空閑區(qū)。如果塊表中沒有空閑區(qū)，則根據(jù)淘汰算法淘汰塊表中的某一行，再填入新的頁號(hào)和塊號(hào)。
我記得計(jì)算機(jī)獲取緩存是按照就近原則的，那它們的優(yōu)先級(jí)呢？
緩存會(huì)根據(jù)存儲(chǔ)速度來選擇最合適的存儲(chǔ)器，離CPU越近的存儲(chǔ)器，速度越快，每字節(jié)的成本越高，同時(shí)容量也因此越小
分層如下：寄存器（離CPU最近，寄存器速度最快）、高速緩存（緩存也是分級(jí)，有L1，L2等緩存）、主存（普通內(nèi)存）、本地磁盤
日常開發(fā)常使緩存軟件，根據(jù)軟件系統(tǒng)所處位置不同，可分
- 客戶端緩存
- 網(wǎng)絡(luò)緩存
- 服務(wù)端緩存
多級(jí)緩存就類似金字塔模式。從上到下依次遞減。類似于一個(gè)漏斗來過濾流量請(qǐng)求。如果絕大多數(shù)請(qǐng)求在客戶端和網(wǎng)絡(luò)交互的部分就抵消，那后端服務(wù)的壓力就會(huì)大大減少。
為什么使用多級(jí)緩存架構(gòu)？
根本在于為網(wǎng)站提供高性能服務(wù)，讓用戶具有更好的用戶體驗(yàn)。以較少的成本獲取更大的性能空間。
聊聊用戶體驗(yàn)
用戶體驗(yàn)這個(gè)詞最早被廣泛認(rèn)知是在20世紀(jì)90年代中期，由用戶體驗(yàn)設(shè)計(jì)師唐納德·諾曼（Donald Norman）提出和推廣。
因信息技術(shù)在移動(dòng)和圖像處理等方面取得的進(jìn)展已經(jīng)使得人機(jī)交互（HCI）技術(shù)幾乎滲透到人類活動(dòng)的所有領(lǐng)域。這導(dǎo)致系統(tǒng)的評(píng)價(jià)指標(biāo)從單純的可用性，擴(kuò)展到用戶體驗(yàn)。
用戶體驗(yàn)在人機(jī)交互技術(shù)發(fā)展過程中受到了相當(dāng)?shù)闹匾暎潢P(guān)注度與 傳統(tǒng)的三大可用性指標(biāo)（即效率、效益和基本主觀滿意度不相上下，甚至在某些方面更為重要。
什么是用戶體驗(yàn)？
ISO 9241-210 標(biāo)準(zhǔn)將用戶體驗(yàn)定義為 “人們對(duì)正在使用或期望使用的產(chǎn)品、系統(tǒng)或者服務(wù)的認(rèn)知印象和回應(yīng)” 。因此，用戶體驗(yàn)是主觀的，且注重實(shí)際應(yīng)用。
用戶體驗(yàn)：即用戶在使用一個(gè)產(chǎn)品或系統(tǒng)之前、使用期間和使用之后的全部感受，包括情感、信仰、喜好、認(rèn)知印象、生理反應(yīng)、心理反應(yīng)、行為和成就等各個(gè)方面。
ISO標(biāo)準(zhǔn)也暗示了可用性也可以作為用戶體驗(yàn)的一個(gè)方面，“可用性標(biāo)準(zhǔn)可以用來評(píng)估用戶體驗(yàn)的一些方面”。不過，該ISO標(biāo)準(zhǔn)并沒有進(jìn)一步闡述用戶體驗(yàn)和系統(tǒng)可用性之間的具體關(guān)系。顯然，這兩者是相互重疊的概念。
也許這就是產(chǎn)品不斷折騰咱技術(shù)的原因，多少得懂點(diǎn)。不知你家產(chǎn)品如何？有無da人的沖動(dòng)
影響用戶體驗(yàn)的因素
影響用戶體驗(yàn)的三因素：
- 使用者的狀態(tài)
- 系統(tǒng)性能
- 環(huán)境
系統(tǒng)性能是軟件產(chǎn)品自身對(duì)用戶體驗(yàn)最關(guān)鍵的因素。 因感受軟件性能的主體是人，不同的人對(duì)于同樣的軟件可能有不同的主觀感受，而且對(duì)于軟件性能關(guān)心的視角也不同。
系統(tǒng)性能是一種非功能特性，它關(guān)注的不是某種特定的功能，而是在完成該功能時(shí)所展示出的及時(shí)性。
關(guān)于系統(tǒng)的性能
系統(tǒng)性能的指標(biāo)一般包括 響應(yīng)時(shí)間、延遲時(shí)間、吞吐量，并發(fā)用戶數(shù)和資源利用率 等幾方面。
響應(yīng)時(shí)間
響應(yīng)時(shí)間是指系統(tǒng)對(duì)用戶請(qǐng)求做出響應(yīng)的時(shí)間，與人對(duì)軟件性能的主觀感受是一致的，完整地記錄了整個(gè)系統(tǒng)處理請(qǐng)求的時(shí)間。
一般響應(yīng)時(shí)間根據(jù)不同項(xiàng)目中的業(yè)務(wù)場景都會(huì)有確切的值，例：一個(gè)請(qǐng)求需保證在100ms、200ms以內(nèi)。
你家首頁響應(yīng)需多少時(shí)間？
由于一個(gè)系統(tǒng)通常會(huì)提供許多功能，而不同功能的處理邏輯也千差萬別，因而不同功能的響應(yīng)時(shí)間也不盡相同，甚至同一功能在不同輸入數(shù)據(jù)的情況下，響應(yīng)時(shí)間也不相同。
所以，我們常說的響應(yīng)時(shí)間通常指該軟件系統(tǒng) 所有功能的平均響應(yīng)時(shí)間 或者 所有功能中的最大響應(yīng)時(shí)間。
有時(shí)候也需要對(duì) 每個(gè)或每組功能討論其平均響應(yīng)時(shí)間和最大響應(yīng)時(shí)間。
在討論軟件性能時(shí)，我們更關(guān)心所開發(fā)軟件自身的 “響應(yīng)時(shí)間”。
比如：php響應(yīng)時(shí)間就是從接受到Nginx請(qǐng)求后，并完成業(yè)務(wù)處理然后響應(yīng)給nginx所消耗的時(shí)間。而用戶就看發(fā)送請(qǐng)求到看到頁面所需的時(shí)間
前者是整個(gè)軟件自身的響應(yīng)，后者是用戶請(qǐng)求響應(yīng)的時(shí)間。觀看角度不同
就這樣，我們可以把 用戶感受到的響應(yīng)時(shí)間 劃分為 呈現(xiàn)時(shí)間和系統(tǒng)響應(yīng)時(shí)間，
- 呈現(xiàn)時(shí)間：客戶端在接收到系統(tǒng)數(shù)據(jù)時(shí)呈現(xiàn)頁面所需的時(shí)間，即頁面渲染加載時(shí)間，
- 系統(tǒng)響應(yīng)時(shí)間：從客戶端發(fā)送請(qǐng)求開始計(jì)時(shí)，直到 服務(wù)器響應(yīng)給客戶端所需的時(shí)間
為啥你的請(qǐng)求就慢呢？
還可以把“系統(tǒng)響應(yīng)時(shí)間”進(jìn)一步分解為網(wǎng)絡(luò)傳輸時(shí)間和“應(yīng)用延遲時(shí)間”，
- 網(wǎng)絡(luò)傳輸時(shí)間： 數(shù)據(jù)在客戶端和服務(wù)器端進(jìn)行傳輸?shù)臅r(shí)間
- 應(yīng)用延遲時(shí)間： 系統(tǒng)實(shí)際處理請(qǐng)求業(yè)務(wù)所需時(shí)間
以后談優(yōu)化，那就應(yīng)該從整個(gè)請(qǐng)求鏈路里著手，針對(duì)呈現(xiàn)、網(wǎng)絡(luò)傳輸、應(yīng)用處理時(shí)間
吞吐量
吞吐量 是指系統(tǒng)在單位時(shí)間內(nèi)處理請(qǐng)求的數(shù)量。
單位時(shí)間是項(xiàng)目自身規(guī)劃響應(yīng)時(shí)間來進(jìn)行描述的，但常用 1s 來衡量處理成功的請(qǐng)求量。
那我網(wǎng)站的吞吐量怎么計(jì)算呢？ 作為小吒的我，還是補(bǔ)了課的
要計(jì)算吞吐量首先要看你的時(shí)間換算和流量情況。
- 單位時(shí)間劃分
假設(shè)一個(gè)發(fā)布系統(tǒng)的廣告頁要滿足30分鐘內(nèi)總訪問量為500w。那平均QPS為： 500w/(30*60) = 2778,大概3000 QPS /S（要預(yù)留空間） - 按天算
假設(shè)某個(gè)信息分類網(wǎng)站首頁日均PV約8000w那平均QPS為： 一天按照4W秒算（晚上不計(jì)算），8000w/4w= 2000,大概2000QPS。
注：
用戶不會(huì)全天都使用軟件，一般晚上不會(huì)使用或者使用人很少。但也分業(yè)務(wù)，你像直播、外賣等。 但一天12小時(shí)基本上滿足一個(gè)用戶當(dāng)天最大使用軟件的時(shí)間。
具體用戶在線使用App的時(shí)間也不確定，具體應(yīng)該根據(jù)自身項(xiàng)目統(tǒng)計(jì)用戶的使用時(shí)間和總流量來計(jì)算平均QPS。利用高峰期流量來計(jì)算最大QPS。
對(duì)于無并發(fā)的應(yīng)用系統(tǒng)而言，吞吐量與響應(yīng)時(shí)間成嚴(yán)格的反比關(guān)系，實(shí)際上此時(shí)吞吐量就是響應(yīng)時(shí)間的倒數(shù)。
無并發(fā)的應(yīng)用都是單機(jī)應(yīng)用，對(duì)于互聯(lián)網(wǎng)或者移動(dòng)互聯(lián)網(wǎng)上的產(chǎn)品而言。
并發(fā)用戶數(shù)
并發(fā)用戶數(shù)是指系統(tǒng)可以同時(shí)承載的正常使用系統(tǒng)功能的用戶數(shù)量，值越大，那處理能力就越強(qiáng)。
資源利用率反映的是在一段時(shí)間內(nèi)資源平均被占用的情況。
從瀏覽器--->網(wǎng)絡(luò)--->應(yīng)用服務(wù)器--->數(shù)據(jù)庫，通過在各個(gè)層面應(yīng)用緩存技術(shù)，將大幅提高提升整個(gè)系統(tǒng)的性能。
例如：緩存離客戶端更近，從緩存請(qǐng)求內(nèi)容比從源服務(wù)器所用時(shí)間更少，呈現(xiàn)速度更快，系統(tǒng)就顯得更靈敏。緩存數(shù)據(jù)的重復(fù)使用，大大降低了用戶的帶寬使用，其實(shí)也是一種變相的省錢（如果流量要付費(fèi)的話），同時(shí)保證了帶寬請(qǐng)求在一個(gè)低水平上，更容易維護(hù)。
所以，使用 緩存技術(shù)，可以降低系統(tǒng)的響應(yīng)時(shí)間，減少網(wǎng)絡(luò)傳輸時(shí)間和應(yīng)用延遲時(shí)間，進(jìn)而提高了系統(tǒng)的吞吐量，增加了系統(tǒng)的并發(fā)用戶數(shù)
利用緩存還可以最小化系統(tǒng)的工作量，使用了緩存就可以不必反復(fù)從數(shù)據(jù)源中查找，緩存所創(chuàng)建或提供的同一條數(shù)據(jù)更好地利用了系統(tǒng)的資源。
因此，緩存是系統(tǒng)調(diào)優(yōu)時(shí)常用且行之有效的手段，無論是操作系統(tǒng)還是應(yīng)用系統(tǒng)，緩存策略無處不在。“緩存為王”本質(zhì)上是系統(tǒng)性能為王，對(duì)用戶而言就是用戶體驗(yàn)為王。
網(wǎng)站架構(gòu)緩存演進(jìn)
起步
最初的網(wǎng)站可能就是一臺(tái)物理主機(jī)，放在IDC或者租用的是云服務(wù)器，上面只運(yùn)行著 應(yīng)用服務(wù)器和數(shù)據(jù)庫，LAMP（linux Apache MySQL PHP）就是這樣流行起來的。
單體架構(gòu)
發(fā)展
由于網(wǎng)站具備一定的特色，吸引了部分用戶的訪問，逐漸會(huì)發(fā)現(xiàn)系統(tǒng)的壓力越來越大，響應(yīng)速度越來越慢，而這個(gè)時(shí)候比較明顯的往往是 數(shù)據(jù)庫與應(yīng)用 的互相影響，于是將應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器從物理上分離開來，變成了兩臺(tái)機(jī)器。讓其不再互相影響，來支撐更高的流量。
中期
隨著訪問網(wǎng)站的人數(shù)越來越多，響應(yīng)速度又開始變慢了，可能是 訪問數(shù)據(jù)庫的操作太多，導(dǎo)致數(shù)據(jù)連接競爭激烈，因此緩存開始登場。
這里不難看出，數(shù)據(jù)庫往往是考慮優(yōu)化的首選，畢竟沒緩存請(qǐng)求直連數(shù)據(jù)庫，而數(shù)據(jù)庫又是數(shù)據(jù)的集中地，查數(shù)據(jù)還會(huì)涉及磁盤I/O。壓力可想而知
若想通過緩存機(jī)制來減少數(shù)據(jù)庫連接資源的競爭和對(duì)數(shù)據(jù)庫讀的壓力，那么可如下選擇：
- 靜態(tài)頁面緩存: 這樣程序上可以不做修改，就能夠很好地減少對(duì)Web服務(wù)器的壓力以及減少對(duì)數(shù)據(jù)庫連接資源的競爭。
- 動(dòng)態(tài)緩存: 將動(dòng)態(tài)頁面里相對(duì)靜態(tài)的部分也緩存起來，因此考慮采用類似的頁面片段緩存策略（通過nginx、Apache配置實(shí)現(xiàn)動(dòng)態(tài)緩存）。
靜態(tài)緩存更傾向于靜態(tài)資源的緩存和瀏覽器的緩存。動(dòng)態(tài)緩存是通過頁面訪問后，再編譯生成緩存文件，提供給后續(xù)請(qǐng)求訪問。有點(diǎn)像模板引擎
那我數(shù)據(jù)庫寫呢?
此刻流量上升，主要針對(duì)訪問，寫請(qǐng)求也會(huì)上升，但性能瓶頸在于數(shù)據(jù)庫的讀操作上。可以說寫還構(gòu)不成太大的威脅。如果寫不夠，那只能擴(kuò)容多個(gè)實(shí)例來應(yīng)對(duì)寫的不足。
高速增長期
隨著訪問量的持續(xù)增加，系統(tǒng)又開始變慢，怎么辦？
使用 數(shù)據(jù)緩存，將系統(tǒng)中重復(fù)獲取的數(shù)據(jù)信息從數(shù)據(jù)庫加載到本地，同時(shí)降低了數(shù)據(jù)庫的負(fù)載。 隨著系統(tǒng)訪問量的再度增加，應(yīng)用服務(wù)器又扛不住了，就開始增加Web服務(wù)器。
那如何保持應(yīng)用服務(wù)器中數(shù)據(jù)緩存信息的同步呢？
例如： 之前緩存的用戶數(shù)據(jù)等，這個(gè)時(shí)候通常會(huì)開始使用緩存同步機(jī)制以及共享文件系統(tǒng)或共享存儲(chǔ)等。 在享受了一段時(shí)間的訪問量高速增長后，系統(tǒng)再次變慢。
開始數(shù)據(jù)庫調(diào)優(yōu)，優(yōu)化數(shù)據(jù)庫自身的緩存，接下來是采用數(shù)據(jù)庫集群以及分庫分表的策略。
分庫分表的規(guī)則是有些復(fù)雜的，考慮增加一個(gè)通用的框架來實(shí)現(xiàn)分庫分表的數(shù)據(jù)訪問，這個(gè)就是數(shù)據(jù)訪問層（Data Access Layer，DAL）。
- 緩存同步機(jī)制：每臺(tái)web服務(wù)器，都會(huì)是保存一份緩存文件，那數(shù)據(jù)之間就需要緩存的同步機(jī)制來完成。
- 共享存儲(chǔ)：共享存儲(chǔ)是指兩個(gè)或多個(gè)處理器共用一個(gè)主存儲(chǔ)器的并行體系結(jié)構(gòu)，像redis。
- 共享文件系統(tǒng)：兩臺(tái)機(jī)器之間的文件系統(tǒng)能夠更加緊密地結(jié)合在一起，讓一臺(tái)主機(jī)上的用戶可以像使用本機(jī)的文件系統(tǒng)一樣使用遠(yuǎn)程機(jī)的文件系統(tǒng)。像Samba和NFS。
后期
該階段可能會(huì)發(fā)現(xiàn)之前的緩存同步方案會(huì)出現(xiàn)問題，因?yàn)閿?shù)據(jù)量太大，導(dǎo)致現(xiàn)在不太可能將緩存存儲(chǔ)在本地后再同步，這樣會(huì)造成同步的時(shí)間延遲從而增大響應(yīng)時(shí)間、數(shù)據(jù)不一致性，數(shù)據(jù)庫耦合緩存。
于是分布式緩存終于來了，將大量的數(shù)據(jù)緩存轉(zhuǎn)移到分布式緩存上。
如果使用共享文件系統(tǒng)或共享存儲(chǔ)有啥問題？
- 共享存儲(chǔ)：多個(gè)服務(wù)訪問一個(gè)存儲(chǔ)，那么容易造成單例性能不足的問題和。如果是并發(fā)讀寫可能會(huì)導(dǎo)致緩存和數(shù)據(jù)不一致問題。
- 共享文件： 多個(gè)服務(wù)壓力太大，因文件I/O開銷大。性能會(huì)導(dǎo)致下降。最終 至此，系統(tǒng)進(jìn)入了無級(jí)縮放的大型網(wǎng)站階段，當(dāng)網(wǎng)站流量增加時(shí)，應(yīng)對(duì)的解決方案就是不斷添加Web服務(wù)器、數(shù)據(jù)庫服務(wù)器、以及緩存服務(wù)器。此時(shí)，大型網(wǎng)站的系統(tǒng)架構(gòu)演變?yōu)閳D所示。
縱觀網(wǎng)站架構(gòu)的發(fā)展歷程，緩存技術(shù)往往就是解除煩惱的靈丹妙藥，這再次證明了什么是緩存為王。
客戶端緩存的實(shí)施方案
客戶端緩存相對(duì)于其他端的緩存而言，要簡單一些，通常是和服務(wù)端以及網(wǎng)絡(luò)側(cè)的應(yīng)用或緩存配合使用。
在互聯(lián)網(wǎng)應(yīng)用中，根據(jù)應(yīng)用區(qū)分有二大類。
- B/S架構(gòu)：頁面緩存和瀏覽器緩存
- 移動(dòng)應(yīng)用：APP自身所使用的緩存 頁面緩存 頁面緩存是什么？
頁面緩存有兩層含義： - 客戶端將頁面自身對(duì)某些元素或全部元素進(jìn)行緩存。簡稱離線應(yīng)用緩存
- 服務(wù)端將靜態(tài)頁面或動(dòng)態(tài)頁面的元素進(jìn)行緩存，然后給客戶端使用。簡稱頁面自身緩存。
頁面緩存是將之前渲染的頁面保存為靜態(tài)文件，當(dāng)用戶再次訪問時(shí)可以避開網(wǎng)絡(luò)連接，從而減少負(fù)載，提升性能和用戶體驗(yàn)。
隨著單頁面應(yīng)用（Single Page Application，SPA）的廣泛使用，加之html5支持了離線緩存和本地存儲(chǔ)，大部分BS應(yīng)用的頁面緩存都可以舉重若輕了。
在HTML5中使用本地緩存的方法，示例代碼如下：
localStorage.setItem("mykey","吒吒輝")
localStorage.getItem("mykey","吒吒輝")
localStorage.removeItem("mykey")
localStorage.clear()
什么是單頁面應(yīng)用?
SPA是在 Web 設(shè)計(jì)上使用單一頁面，利用 JAVAScript 操作 Dom 的技術(shù)實(shí)現(xiàn)各種應(yīng)用。此模式下一個(gè)系統(tǒng)只加載一次資源，之后的操作交互、數(shù)據(jù)交互是通過路由、ajax來進(jìn)行，頁面并沒有刷新。
常見的路由形式如：http:.//xxx/shell.htm1#page1。
一般在Vue下使用很明顯。像商城活動(dòng)頁、登錄頁這種都是很好的SPA落地實(shí)踐。
HTML5提供的離線應(yīng)用緩存機(jī)制，使得網(wǎng)頁應(yīng)用可以離線使用(無網(wǎng)絡(luò)也可訪問)，這種機(jī)制在瀏覽器上支持度非常廣，可以放心地使用該特性來加速頁面的訪問。開啟離線緩存的步驟如下：
- 準(zhǔn)備用于描述頁面需要緩存的資源列表清單文件 （manifest text/cache-manifest）。
注：manifest 文件需要配置正確的 MIME-type，即 "text/cache-manifest"。必須在 web 服務(wù)器上進(jìn)行配置。
例：nginx要修改配置目錄下的 mime.types 文件，添加manifest文件映射：
text/cache-manifest manifest;
- 在需要離線使用的頁面中的 html 里添加 manifest屬性，指定緩存清單文件的路徑。 離線緩存的工作流如圖所示。
目前html標(biāo)簽的manifest屬性已廢棄了，可移步 webpack。
頁面緩存
由圖可知：
- 當(dāng)瀏覽器訪問一個(gè)包含manifest屬性的頁面時(shí)，如果應(yīng)用的緩存不存在，瀏覽器會(huì)加載文檔，獲取所有在清單文件中列出的文件，生成初始緩存。
- 當(dāng)后續(xù)請(qǐng)求再次對(duì)該文檔再次訪問時(shí)，瀏覽器會(huì)直接從應(yīng)用緩存中加載頁面以及在清單文件中列出的資源。同時(shí)，瀏覽器還會(huì)向 window.applicationCache 對(duì)象發(fā)送一個(gè)表示檢查的事件，以獲取清單文件。
- 如果當(dāng)前緩存的清單副本是最新的，瀏覽器將向window.applicationCache對(duì)象發(fā)送一個(gè)表示無須更新的事件，從而結(jié)束更新過程。如果在服務(wù)端修改了任何緩存資源，必須同時(shí)修改清單文件，這樣瀏覽器才能知道要重新獲取資源。
- 如果清單文件已經(jīng)改變，那么文件中列出的所有文件會(huì)被重新獲取并放到一個(gè)臨時(shí)緩存中。對(duì)于每個(gè)加入到臨時(shí)緩存中的文件，瀏覽器會(huì)向window.applicationCache對(duì)象發(fā)送一個(gè)表示進(jìn)行中的事件。
- 一旦所有文件都獲取成功，它們會(huì)自動(dòng)移動(dòng)到真正的離線緩存中，并向window.applicationCache對(duì)象發(fā)送一個(gè)表示已經(jīng)緩存的事件。鑒于文檔早已經(jīng)從緩存加載到瀏覽器中，所以更新后的文檔不會(huì)重新渲染，直到頁面重新加載。
注意：manifest文件中列出的資源URL必須和manifest本身使用同樣的網(wǎng)絡(luò)協(xié)議，詳情可參考W3C相關(guān)的標(biāo)準(zhǔn)文檔。
瀏覽器緩存
瀏覽器緩存是根據(jù)一套與服務(wù)器約定的規(guī)則進(jìn)行工作的，工作規(guī)則很簡單：檢查以確保副本為最新，通常只要一次會(huì)話請(qǐng)求。
瀏覽器會(huì)在硬盤上專門開辟一個(gè)空間來存儲(chǔ)資源副本作為緩存。
在用戶觸發(fā) 后退操作或點(diǎn)擊 一個(gè)之前看過鏈接的時(shí)候，瀏覽器緩存會(huì)很管用。如果訪問系統(tǒng)中的同一張圖片，該圖片可以從瀏覽器緩存中調(diào)出并幾乎立即顯現(xiàn)出來。
HTTP1.0
對(duì)瀏覽器而言，HTTP1.0提供了一些很基本的緩存特性，參數(shù)例如:
- 在服務(wù)器側(cè)設(shè)置 Expires的HTTP頭 來告訴客戶端在重新請(qǐng)求文件之前緩存多久是有效的.
- 請(qǐng)求通過 if-modified-since 的條件判斷使用緩存。
- Last-Modified：Last-Modified是響應(yīng)頭，web容器會(huì)把最后修改時(shí)間告訴客戶端
每次請(qǐng)求web容器時(shí)會(huì)先檢查客戶端緩存資源是否還有效，無效則會(huì)把上次服務(wù)端響應(yīng)的最后修改時(shí)間作為 If-Modified-Since 的值發(fā)送給服務(wù)器進(jìn)行判斷，如果文件沒有改變，服務(wù)器采用 304-Not Modified做響應(yīng)頭和一個(gè)為空的響應(yīng)體。客戶端收到304響應(yīng)，就可以使用緩存的文件版本了。
為什么客戶端無效，還要發(fā)送HTTP請(qǐng)求來判斷文件是否修改呢？
如果緩存資源有效那就是直接來讀取客戶端緩存，不需要發(fā)送HTTP請(qǐng)求。但有一些情況就需注意，比如當(dāng)用戶按F5或者點(diǎn)擊Refresh按鈕的時(shí)候就算對(duì)于有Expires的URI，一樣也會(huì)發(fā)一個(gè)HTTP請(qǐng)求出去，所以就需要通過Last-Modified來判斷。
而且客戶端和服務(wù)端的時(shí)間可能不一樣，這樣就會(huì)導(dǎo)致客戶端已過期，但服務(wù)端并沒有。如果有判斷機(jī)制，那么響應(yīng)就會(huì)減少響應(yīng)體的數(shù)據(jù)發(fā)送。 或者客戶端只是單純的 Expires 過期，但資源并沒改變，這時(shí)就需要檢查文件是否有變化。
HTTP 1.1
HTTP 1.1有了較大的增強(qiáng)，緩存系統(tǒng)被形式化了，引入了實(shí)體標(biāo)簽 **e-tag 和 Cache-Control。
- e-tag 是文件或?qū)ο蟮奈ㄒ粯?biāo)識(shí)。每次請(qǐng)求攜帶e-tage參數(shù)進(jìn)行訪問，文件是否被更新。
- Cache-Control：相對(duì)過期，從客戶端收到響應(yīng)時(shí)間時(shí)開始計(jì)算，多少秒后緩存會(huì)過期。 具體字段信息如下： max-age：用來設(shè)置資源（representations）可以被緩存多長時(shí)間，單位為秒； s-maxage：和max-age是一樣的，不過它只針對(duì)代理服務(wù)器緩存而言； - public：指示響應(yīng)可被任何緩存區(qū)緩存； private：只能針對(duì)個(gè)人用戶，而不能被代理服務(wù)器緩存； no-cache：強(qiáng)制客戶端直接向服務(wù)器發(fā)送請(qǐng)求,也就是說每次請(qǐng)求都必須向服務(wù)器發(fā)送。服務(wù)器接收到請(qǐng)求，判斷資源是否變更，否則返回新內(nèi)容，否則返回304。 no-store：禁止一切緩存（這個(gè)是響應(yīng)不被緩存的意思）
- If-None-Match：第一次發(fā)送etag字段響應(yīng)給客戶端后，下次請(qǐng)求客戶端會(huì)同時(shí)發(fā)送一個(gè)If-None-Match來判斷數(shù)據(jù)是否發(fā)送變化，而它的值就是Etag的值
以Web瀏覽器使用 e-tag 為例，如下圖所示。
在配置了 Last-Modified/ETag 的情況下，瀏覽器再次訪問統(tǒng)一URI的資源時(shí)，還是會(huì)發(fā)送請(qǐng)求到服務(wù)器詢問文件是否已經(jīng)修改，如果沒有，服務(wù)器會(huì)生成304-Not Modified應(yīng)答和一個(gè)空的響應(yīng)體給瀏覽器，瀏覽器則直接從本地緩存取數(shù)據(jù)；如果數(shù)據(jù)有變化，就將整個(gè)數(shù)據(jù)重新發(fā)給瀏覽器。
匯總
Last-Modified/ETag 與 Cache-Control/Expires的作用是不一樣的。前者是每次詢問實(shí)體版本是否有變化，后者是直接檢查本地的緩存還在有效的時(shí)間范圍內(nèi)，如果在就不會(huì)發(fā)送任何請(qǐng)求。
- 兩者一起使用時(shí)，Cache-Control/Expires的優(yōu)先級(jí)要高于Last-Modified/ETag。
當(dāng)本地副本根據(jù) Cache-Control/Expires 判斷是否還在有效期內(nèi)，如果不在，則會(huì)再次發(fā)送請(qǐng)求去服務(wù)器詢問修改時(shí)間（Last-Modified）或?qū)嶓w標(biāo)識(shí)（e-tag）。
Cache-Control與Expires的功能一致，都是指當(dāng)前資源的有效期，控制瀏覽器是直接從瀏覽器緩存取數(shù)據(jù)還是重新發(fā)請(qǐng)求到服務(wù)器取數(shù)據(jù)。只不過Cache-Control的選擇更多，設(shè)置更細(xì)致，如果同時(shí)設(shè)置的話，其優(yōu)先級(jí)高于Expires。
一般情況下，使用 Cache-Control/Expires 會(huì)配合 Last-Modified/ETag 一起使用，因?yàn)榧词狗?wù)器設(shè)置緩存時(shí)間，當(dāng)用戶點(diǎn)擊 刷新 按鈕時(shí)，瀏覽器會(huì)忽略緩存繼續(xù)向服務(wù)器發(fā)送請(qǐng)求，這時(shí)Last-Modified/ETag將能夠很好利用服務(wù)端的返回碼304，從而減少響應(yīng)開銷。
通過在HTML頁面的節(jié)點(diǎn)中加入meta標(biāo)簽，可告訴瀏覽器當(dāng)前頁面不被緩存，每次訪問都需要去服務(wù)器拉取。代碼如下：
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
只不過，只有部分瀏覽器才支持這一用法，而且一般 緩存代理服務(wù)器都不支持，因?yàn)榇肀旧聿唤馕?HTML 的內(nèi)容。 瀏覽器緩存能夠極大地提升終端用戶的體驗(yàn)，那么，用戶在使用瀏覽器的時(shí)候，會(huì)有各種操作，如輸入地址后回車、按F5刷新等等，這些行為對(duì)緩存的影響如下所示。
APP端緩存
盡管混合編程（hybrid programming）已成為時(shí)尚，吵在尖端，但移動(dòng)互聯(lián)網(wǎng)目前還是原生應(yīng)用（APP）的天下。無論大小型APP，靈活的緩存不僅大大減輕了服務(wù)器的壓力，而且會(huì)因更快速的用戶體驗(yàn)而方便用戶。 如何把APP 緩存對(duì)于業(yè)務(wù)組件透明，以及APP緩存數(shù)據(jù)的及時(shí)更新，是APP緩存能否成功應(yīng)用起來的關(guān)鍵。
組件透明是什么？
即組件對(duì)調(diào)用者來說沒有什么影響，也不需要維護(hù)。開箱即用。
APP緩存可使用哪些緩存？
APP可以將內(nèi)容緩存在 內(nèi)存、文件或本地?cái)?shù)據(jù)庫（例如SQLite）中，但基于 內(nèi)存的緩存 要謹(jǐn)慎使用。
本地庫操作
APP使用數(shù)據(jù)庫緩存的方法：
- 在下載完數(shù)據(jù)文件后，把文件的相關(guān)信息(如URL、路徑、下載時(shí)間、過期時(shí)間等)存放到數(shù)據(jù)庫.
- 等下次請(qǐng)求下載的時(shí)候，根據(jù)URL先從數(shù)據(jù)庫中查詢，如果查詢到當(dāng)前時(shí)間并未過期，就根據(jù)路徑讀取本地文件，實(shí)現(xiàn)緩存的效果。
優(yōu)點(diǎn)：方法具有靈活存放文件的屬性，進(jìn)而提供了很大的擴(kuò)展性，可以為其他的功能提供良好的支持。
缺點(diǎn)：信息存儲(chǔ)過多，存儲(chǔ)容量會(huì)降低。所以要根據(jù)業(yè)務(wù)選擇合適主要的信息存儲(chǔ)
注意數(shù)據(jù)庫緩存的清理機(jī)制 。
文件操作
對(duì)APP中的某些界面，可以采用文件緩存的方法。這種方法使用文件操作的相關(guān)API得到文件的最后修改時(shí)間，與當(dāng)前時(shí)間判斷是否過期，從而實(shí)現(xiàn)緩存效果。
但需要注意的是，不同類型文件的緩存時(shí)間不一樣。比如：
文件類型：
- 圖片文件的內(nèi)容是相對(duì)不變的，直到最終被清理掉，APP可以永遠(yuǎn)讀取緩存中的圖片內(nèi)容。
- 配置文件中的內(nèi)容是可能更新的，需要設(shè)置一個(gè)可接受的緩存時(shí)間。同時(shí)，不同環(huán)境下的緩存時(shí)間標(biāo)準(zhǔn)也是不一樣的。
網(wǎng)絡(luò)環(huán)境：
- WiFi網(wǎng)絡(luò)環(huán)境下，緩存時(shí)間可以設(shè)置短一點(diǎn)，一是網(wǎng)速較快，二是不產(chǎn)生流量費(fèi)。
- 移動(dòng)數(shù)據(jù)流量環(huán)境下，緩存時(shí)間可以設(shè)置長一點(diǎn)，節(jié)省流量，而且用戶體驗(yàn)也更好。
在IOS開發(fā)中，SDWebImage是一個(gè)很棒的圖片緩存框架，主要類組成的結(jié)構(gòu)如下所示。
SDWebImage 是個(gè)比較大的類庫，提供一個(gè)UIImageView的類以支持遠(yuǎn)程加載來自網(wǎng)絡(luò)的圖片，具有緩存管理、異步下載、同一個(gè)URL下載次數(shù)控制和優(yōu)化等特征。使用時(shí)，只需要在頭文件中引入 #import"UIImageView+WebCache.h" 即可調(diào)用異步加載圖片方法：
(void)setImageWithURL:(NSURL *)url placeholderImage:(UIImage *)placeholder options:(SDWebImageOptions)options;
URL是圖片的地址
- placeholderImage是網(wǎng)絡(luò)圖片在尚未加載成功時(shí)顯示的圖像
- SDWebImageOptions是相關(guān)選項(xiàng)。
默認(rèn)情況下，SDWebImage會(huì)忽略Header中的緩存設(shè)置，將圖片以URL為key進(jìn)行保存，URL與圖片是一個(gè)映射關(guān)系。在APP請(qǐng)求同一個(gè)URL時(shí)，SDWebImage會(huì)從緩存中取得圖片。將第三個(gè)參數(shù)設(shè)置為SDWebImageRefreshCached就可以實(shí)現(xiàn)圖片更新操作，例如：
NSURL *url = [NSURL URLWithString:@"http://www.zhazhahui.com/image.png"];
UIImage *defaultImage = [UIImage imageNamed:@"zhazhahui.png"];
[self.imageView setImageWithURL:url placeholderImage:defaultImage options:SDWebImageRefreshCached];
SDWebImage中有兩種緩存
- 磁盤緩存
- 內(nèi)存緩存
框架都提供了相應(yīng)的清理方法：
[[[SDWebImageManager sharedManager] imageCache] clearDisk];
[[[SDWebImageManager sharedManager] imageCache] clearMemory];
要注意的是，在iOS7中，緩存機(jī)制做了修改，使用上述兩個(gè)方法只清除了SDWebImage的緩存，沒有清除系統(tǒng)的緩存，所以可以在清除緩存的代碼中添加以下代碼：
[[NSURLCache sharedURLCache] removeAllCachedResponses];
最后：
- 緩存根據(jù)存在方式有系統(tǒng)、硬件、軟件三類。
- 軟件根據(jù)場景客戶端、網(wǎng)絡(luò)、分布式緩存
- 用戶體驗(yàn)**：即用戶在使用一個(gè)產(chǎn)品或系統(tǒng)之前、使用期間和使用之后的全部感受。
- 系統(tǒng)性能指標(biāo)有響應(yīng)時(shí)間、延遲時(shí)間、吞吐量，并發(fā)用戶數(shù)和資源利用率等幾方面
- 網(wǎng)站架構(gòu)演講，經(jīng)歷起步、發(fā)展、中期、高速增長、后期
- 客戶端緩存分為頁面緩存、瀏覽器緩存、APP緩存
以上就是本文分享，但內(nèi)容未完，這還是開胃小菜。若有幫助，歡迎關(guān)注、分享+收藏額
需獲取本系列總結(jié)大綱直接后臺(tái)私信回復(fù)“分布式緩存”即可免費(fèi)領(lǐng)取！！！
絮絮叨叨
其實(shí)，大綱很早就寫好了，但對(duì)里面內(nèi)容的呈現(xiàn)方式，細(xì)節(jié)原理就一直不知道如何撰寫才能達(dá)到明朗的效果。
這文章花了我非常多時(shí)間。哎，菜就是菜，吒吒輝我也不找借口了。。。 吒就是吒
還是太弱
如果大家在閱讀過程中，發(fā)現(xiàn)了不理解或有錯(cuò)誤的地方，歡迎跟在底部留言，你們的每一條留言，吒吒輝都會(huì)回復(fù)。
