一談緩存，內心頓時豁然開朗。迫于key-value的形式，總感覺輕風拂面，楊柳依依，一切都盡在我掌握之中。猶如那一眼相中佳人的沖動，腦子里盡是佳人的容顏。

那緩存如果站在網站架構的角度，你知道它的設計原理和影響作用嗎？

絮叨

在商業的世界里，常說的一句話是 "現金為王"。在互聯網、移動互聯網乃至整個軟件技術的世界里面，與之相近的就是 "緩存為王"。

為何這么說呢？

試想一下，你個完整的網絡請求（HTTP、SOAP、RPC等），如果在執行過程的某個部分尚有緩存，是不是就能提前響應給客戶端呢？

為何現在很多中大型公司在面試時，對緩存的應用、原理、高可用等一系列問題，都一撲啦的扔給你，讓你難以招架。原因都在這。

什么是緩存？

緩存：存儲在計算機上的一個原始數據復制，以便于訪問
--維基百科

緩存是系統快速響應中的一種關鍵技術，是一組被保存起來以備將來使用的東西。介于應用開發和系統開發之間，是產品經理經常顧及不到的地方，也是技術架構設計中的非功能性約束。

應用開發我知道，這系統緩存是個什么情況呀，小吒哥？
不要著急，往后面看

什么是多級緩存架構？

顧名思義，由多個維度共同組成的緩存工程。因為緩存在不同的場景有著不同的意義。采用的技術手段也不同。

按緩存存在形式分：

硬件緩存（如CPU、硬盤等）
操作系統緩存
軟件緩存系統緩存是什么？

操作系統是管理計算機硬件與軟件資源的計算機程序，而硬、軟件件運行速度的快慢基本由緩存決定，緩存的容量越大，相應的硬件運行速度也就越快。所以系統緩存就是操作系統調用硬件資源（內存、文件等）和調用應用程序時，能夠啟動加速執行的作用。

總結：操作系統存調用涉及到有緩存的部分，都可算系統緩存

軟件運行都需建立在操作系統之上，在運行時需要把程序裝載到內存中，但軟件執行操作內存時都是基于虛擬內存映射的機制，并不是直接操作物理內存。虛擬內存以塊表（內存塊組成的表格）的形式來存儲相關資源。

注：物理內存組成上由多個方塊狀的元素構成,該元素是內存管理的最小單位。每一個元素有8個小電容,存儲8個bit,即1字節。
是不是和磁盤塊差不多， ^_^ 。吒吒輝懂你呀

為提高系統的存取速度，在 地址映射機制中增加了一個小容量的聯想寄存器，即塊表。

內存塊表

它 用來存放當前訪問最頻繁的少數活動頁面的頁數。當某用戶需存取數據時，根據數據所在的邏輯頁號在塊表中找到對應的內存塊號，再聯系其頁內地址，形成物理地址。

總結：讀取數據時-->先找邏輯頁--->排查內存塊號--->獲得物理層內存表示頁內地址---->物理地址

如果塊表中沒有相應的邏輯頁號，則地址映射仍然可以通過內存中的頁表進行操作，只是它得到是空閑塊號，必須將該塊號填入塊表中的空閑區。如果塊表中沒有空閑區，則根據淘汰算法淘汰塊表中的某一行，再填入新的頁號和塊號。

我記得計算機獲取緩存是按照就近原則的，那它們的優先級呢？

緩存會根據存儲速度來選擇最合適的存儲器，離CPU越近的存儲器，速度越快，每字節的成本越高，同時容量也因此越小

分層如下：寄存器（離CPU最近，寄存器速度最快）、高速緩存（緩存也是分級，有L1，L2等緩存）、主存（普通內存）、本地磁盤

日常開發常使緩存軟件，根據軟件系統所處位置不同，可分

客戶端緩存
網絡緩存
服務端緩存

多級緩存就類似金字塔模式。從上到下依次遞減。類似于一個漏斗來過濾流量請求。如果絕大多數請求在客戶端和網絡交互的部分就抵消，那后端服務的壓力就會大大減少。

為什么使用多級緩存架構？

根本在于為網站提供高性能服務，讓用戶具有更好的用戶體驗。以較少的成本獲取更大的性能空間。

聊聊用戶體驗

用戶體驗這個詞最早被廣泛認知是在20世紀90年代中期，由用戶體驗設計師唐納德·諾曼（Donald Norman）提出和推廣。

因信息技術在移動和圖像處理等方面取得的進展已經使得人機交互（HCI）技術幾乎滲透到人類活動的所有領域。這導致系統的評價指標從單純的可用性，擴展到用戶體驗。

用戶體驗在人機交互技術發展過程中受到了相當的重視，其關注度與 傳統的三大可用性指標（即效率、效益和基本主觀滿意度不相上下，甚至在某些方面更為重要。

什么是用戶體驗？

ISO 9241-210 標準將用戶體驗定義為 “人們對正在使用或期望使用的產品、系統或者服務的認知印象和回應” 。因此，用戶體驗是主觀的，且注重實際應用。

用戶體驗：即用戶在使用一個產品或系統之前、使用期間和使用之后的全部感受，包括情感、信仰、喜好、認知印象、生理反應、心理反應、行為和成就等各個方面。

ISO標準也暗示了可用性也可以作為用戶體驗的一個方面，“可用性標準可以用來評估用戶體驗的一些方面”。不過，該ISO標準并沒有進一步闡述用戶體驗和系統可用性之間的具體關系。顯然，這兩者是相互重疊的概念。

也許這就是產品不斷折騰咱技術的原因，多少得懂點。不知你家產品如何？有無da人的沖動

影響用戶體驗的因素

影響用戶體驗的三因素：

使用者的狀態
系統性能
環境

系統性能是軟件產品自身對用戶體驗最關鍵的因素。 因感受軟件性能的主體是人，不同的人對于同樣的軟件可能有不同的主觀感受，而且對于軟件性能關心的視角也不同。

系統性能是一種非功能特性，它關注的不是某種特定的功能，而是在完成該功能時所展示出的及時性。

關于系統的性能

系統性能的指標一般包括 響應時間、延遲時間、吞吐量，并發用戶數和資源利用率 等幾方面。

響應時間

響應時間是指系統對用戶請求做出響應的時間，與人對軟件性能的主觀感受是一致的，完整地記錄了整個系統處理請求的時間。

一般響應時間根據不同項目中的業務場景都會有確切的值，例：一個請求需保證在100ms、200ms以內。

你家首頁響應需多少時間？

由于一個系統通常會提供許多功能，而不同功能的處理邏輯也千差萬別，因而不同功能的響應時間也不盡相同，甚至同一功能在不同輸入數據的情況下，響應時間也不相同。

所以，我們常說的響應時間通常指該軟件系統 所有功能的平均響應時間 或者 所有功能中的最大響應時間。

有時候也需要對 每個或每組功能討論其平均響應時間和最大響應時間。

在討論軟件性能時，我們更關心所開發軟件自身的 “響應時間”。

比如：php響應時間就是從接受到Nginx請求后，并完成業務處理然后響應給nginx所消耗的時間。而用戶就看發送請求到看到頁面所需的時間

前者是整個軟件自身的響應，后者是用戶請求響應的時間。觀看角度不同

就這樣，我們可以把 用戶感受到的響應時間 劃分為 呈現時間和系統響應時間，

呈現時間：客戶端在接收到系統數據時呈現頁面所需的時間，即頁面渲染加載時間，
系統響應時間：從客戶端發送請求開始計時，直到服務器響應給客戶端所需的時間

為啥你的請求就慢呢？

還可以把“系統響應時間”進一步分解為網絡傳輸時間和“應用延遲時間”，

網絡傳輸時間： 數據在客戶端和服務器端進行傳輸的時間
應用延遲時間： 系統實際處理請求業務所需時間

以后談優化，那就應該從整個請求鏈路里著手，針對呈現、網絡傳輸、應用處理時間

吞吐量

吞吐量 是指系統在單位時間內處理請求的數量。

單位時間是項目自身規劃響應時間來進行描述的，但常用 1s 來衡量處理成功的請求量。

那我網站的吞吐量怎么計算呢？作為小吒的我，還是補了課的
要計算吞吐量首先要看你的時間換算和流量情況。

單位時間劃分
假設一個發布系統的廣告頁要滿足30分鐘內總訪問量為500w。那平均QPS為： 500w/(30*60) = 2778,大概3000 QPS /S（要預留空間）
按天算
假設某個信息分類網站首頁日均PV約8000w那平均QPS為：一天按照4W秒算（晚上不計算），8000w/4w= 2000,大概2000QPS。

注：
用戶不會全天都使用軟件，一般晚上不會使用或者使用人很少。但也分業務，你像直播、外賣等。但一天12小時基本上滿足一個用戶當天最大使用軟件的時間。

具體用戶在線使用App的時間也不確定，具體應該根據自身項目統計用戶的使用時間和總流量來計算平均QPS。利用高峰期流量來計算最大QPS。

對于無并發的應用系統而言，吞吐量與響應時間成嚴格的反比關系，實際上此時吞吐量就是響應時間的倒數。

無并發的應用都是單機應用，對于互聯網或者移動互聯網上的產品而言。

并發用戶數

并發用戶數是指系統可以同時承載的正常使用系統功能的用戶數量，值越大，那處理能力就越強。

資源利用率反映的是在一段時間內資源平均被占用的情況。

從瀏覽器--->網絡--->應用服務器--->數據庫，通過在各個層面應用緩存技術，將大幅提高提升整個系統的性能。

例如：緩存離客戶端更近，從緩存請求內容比從源服務器所用時間更少，呈現速度更快，系統就顯得更靈敏。緩存數據的重復使用，大大降低了用戶的帶寬使用，其實也是一種變相的省錢（如果流量要付費的話），同時保證了帶寬請求在一個低水平上，更容易維護。

所以，使用緩存技術，可以降低系統的響應時間，減少網絡傳輸時間和應用延遲時間，進而提高了系統的吞吐量，增加了系統的并發用戶數

利用緩存還可以最小化系統的工作量，使用了緩存就可以不必反復從數據源中查找，緩存所創建或提供的同一條數據更好地利用了系統的資源。

因此，緩存是系統調優時常用且行之有效的手段，無論是操作系統還是應用系統，緩存策略無處不在。“緩存為王”本質上是系統性能為王，對用戶而言就是用戶體驗為王。

網站架構緩存演進

起步

最初的網站可能就是一臺物理主機，放在IDC或者租用的是云服務器，上面只運行著 應用服務器和數據庫，LAMP（linux Apache MySQL PHP）就是這樣流行起來的。

單體架構

發展

由于網站具備一定的特色，吸引了部分用戶的訪問，逐漸會發現系統的壓力越來越大，響應速度越來越慢，而這個時候比較明顯的往往是 數據庫與應用 的互相影響，于是將應用服務器和數據庫服務器從物理上分離開來，變成了兩臺機器。讓其不再互相影響，來支撐更高的流量。

中期

隨著訪問網站的人數越來越多，響應速度又開始變慢了，可能是 訪問數據庫的操作太多，導致數據連接競爭激烈，因此緩存開始登場。

這里不難看出，數據庫往往是考慮優化的首選，畢竟沒緩存請求直連數據庫，而數據庫又是數據的集中地，查數據還會涉及磁盤I/O。壓力可想而知

若想通過緩存機制來減少數據庫連接資源的競爭和對數據庫讀的壓力，那么可如下選擇：

靜態頁面緩存: 這樣程序上可以不做修改，就能夠很好地減少對Web服務器的壓力以及減少對數據庫連接資源的競爭。
動態緩存: 將動態頁面里相對靜態的部分也緩存起來，因此考慮采用類似的頁面片段緩存策略（通過nginx、Apache配置實現動態緩存）。

靜態緩存更傾向于靜態資源的緩存和瀏覽器的緩存。動態緩存是通過頁面訪問后，再編譯生成緩存文件，提供給后續請求訪問。有點像模板引擎

那我數據庫寫呢?

此刻流量上升，主要針對訪問，寫請求也會上升，但性能瓶頸在于數據庫的讀操作上。可以說寫還構不成太大的威脅。如果寫不夠，那只能擴容多個實例來應對寫的不足。

高速增長期

隨著訪問量的持續增加，系統又開始變慢，怎么辦？

使用 數據緩存，將系統中重復獲取的數據信息從數據庫加載到本地，同時降低了數據庫的負載。隨著系統訪問量的再度增加，應用服務器又扛不住了，就開始增加Web服務器。

那如何保持應用服務器中數據緩存信息的同步呢？

例如：之前緩存的用戶數據等，這個時候通常會開始使用緩存同步機制以及共享文件系統或共享存儲等。在享受了一段時間的訪問量高速增長后，系統再次變慢。

開始數據庫調優，優化數據庫自身的緩存，接下來是采用數據庫集群以及分庫分表的策略。

分庫分表的規則是有些復雜的，考慮增加一個通用的框架來實現分庫分表的數據訪問，這個就是數據訪問層（Data Access Layer，DAL）。

緩存同步機制：每臺web服務器，都會是保存一份緩存文件，那數據之間就需要緩存的同步機制來完成。
共享存儲：共享存儲是指兩個或多個處理器共用一個主存儲器的并行體系結構，像redis。
共享文件系統：兩臺機器之間的文件系統能夠更加緊密地結合在一起，讓一臺主機上的用戶可以像使用本機的文件系統一樣使用遠程機的文件系統。像Samba和NFS。

后期

該階段可能會發現之前的緩存同步方案會出現問題，因為數據量太大，導致現在不太可能將緩存存儲在本地后再同步，這樣會造成同步的時間延遲從而增大響應時間、數據不一致性，數據庫耦合緩存。
于是分布式緩存終于來了，將大量的數據緩存轉移到分布式緩存上。

如果使用共享文件系統或共享存儲有啥問題？

共享存儲：多個服務訪問一個存儲，那么容易造成單例性能不足的問題和。如果是并發讀寫可能會導致緩存和數據不一致問題。
共享文件：多個服務壓力太大，因文件I/O開銷大。性能會導致下降。最終至此，系統進入了無級縮放的大型網站階段，當網站流量增加時，應對的解決方案就是不斷添加Web服務器、數據庫服務器、以及緩存服務器。此時，大型網站的系統架構演變為圖所示。

縱觀網站架構的發展歷程，緩存技術往往就是解除煩惱的靈丹妙藥，這再次證明了什么是緩存為王。

客戶端緩存的實施方案

客戶端緩存相對于其他端的緩存而言，要簡單一些，通常是和服務端以及網絡側的應用或緩存配合使用。

在互聯網應用中，根據應用區分有二大類。

B/S架構：頁面緩存和瀏覽器緩存
移動應用：APP自身所使用的緩存 頁面緩存頁面緩存是什么？
頁面緩存有兩層含義：
客戶端將頁面自身對某些元素或全部元素進行緩存。簡稱離線應用緩存
服務端將靜態頁面或動態頁面的元素進行緩存，然后給客戶端使用。簡稱頁面自身緩存。

頁面緩存是將之前渲染的頁面保存為靜態文件，當用戶再次訪問時可以避開網絡連接，從而減少負載，提升性能和用戶體驗。

隨著單頁面應用（Single Page Application，SPA）的廣泛使用，加之html5支持了離線緩存和本地存儲，大部分BS應用的頁面緩存都可以舉重若輕了。

在HTML5中使用本地緩存的方法，示例代碼如下：

localStorage.setItem("mykey","吒吒輝")
localStorage.getItem("mykey","吒吒輝")
localStorage.removeItem("mykey")
localStorage.clear()

什么是單頁面應用?

SPA是在 Web 設計上使用單一頁面，利用 JAVAScript 操作 Dom 的技術實現各種應用。此模式下一個系統只加載一次資源，之后的操作交互、數據交互是通過路由、ajax來進行，頁面并沒有刷新。

常見的路由形式如：http:.//xxx/shell.htm1#page1。
一般在Vue下使用很明顯。像商城活動頁、登錄頁這種都是很好的SPA落地實踐。

HTML5提供的離線應用緩存機制，使得網頁應用可以離線使用(無網絡也可訪問)，這種機制在瀏覽器上支持度非常廣，可以放心地使用該特性來加速頁面的訪問。開啟離線緩存的步驟如下：

準備用于描述頁面需要緩存的資源列表清單文件（manifest text/cache-manifest）。

注：manifest 文件需要配置正確的 MIME-type，即 "text/cache-manifest"。必須在 web 服務器上進行配置。

例：nginx要修改配置目錄下的 mime.types 文件，添加manifest文件映射：

  text/cache-manifest            manifest;

在需要離線使用的頁面中的 html 里添加 manifest屬性，指定緩存清單文件的路徑。離線緩存的工作流如圖所示。

目前html標簽的manifest屬性已廢棄了，可移步 webpack。

頁面緩存

由圖可知：

當瀏覽器訪問一個包含manifest屬性的頁面時，如果應用的緩存不存在，瀏覽器會加載文檔，獲取所有在清單文件中列出的文件，生成初始緩存。
當后續請求再次對該文檔再次訪問時，瀏覽器會直接從應用緩存中加載頁面以及在清單文件中列出的資源。同時，瀏覽器還會向 window.applicationCache 對象發送一個表示檢查的事件，以獲取清單文件。
如果當前緩存的清單副本是最新的，瀏覽器將向window.applicationCache對象發送一個表示無須更新的事件，從而結束更新過程。如果在服務端修改了任何緩存資源，必須同時修改清單文件，這樣瀏覽器才能知道要重新獲取資源。
如果清單文件已經改變，那么文件中列出的所有文件會被重新獲取并放到一個臨時緩存中。對于每個加入到臨時緩存中的文件，瀏覽器會向window.applicationCache對象發送一個表示進行中的事件。
一旦所有文件都獲取成功，它們會自動移動到真正的離線緩存中，并向window.applicationCache對象發送一個表示已經緩存的事件。鑒于文檔早已經從緩存加載到瀏覽器中，所以更新后的文檔不會重新渲染，直到頁面重新加載。

注意：manifest文件中列出的資源URL必須和manifest本身使用同樣的網絡協議，詳情可參考W3C相關的標準文檔。

瀏覽器緩存

瀏覽器緩存是根據一套與服務器約定的規則進行工作的，工作規則很簡單：檢查以確保副本為最新，通常只要一次會話請求。

瀏覽器會在硬盤上專門開辟一個空間來存儲資源副本作為緩存。

在用戶觸發 后退操作或點擊 一個之前看過鏈接的時候，瀏覽器緩存會很管用。如果訪問系統中的同一張圖片，該圖片可以從瀏覽器緩存中調出并幾乎立即顯現出來。

HTTP1.0

對瀏覽器而言，HTTP1.0提供了一些很基本的緩存特性，參數例如:

在服務器側設置 Expires的HTTP頭 來告訴客戶端在重新請求文件之前緩存多久是有效的.
請求通過 if-modified-since 的條件判斷使用緩存。
Last-Modified：Last-Modified是響應頭，web容器會把最后修改時間告訴客戶端

每次請求web容器時會先檢查客戶端緩存資源是否還有效，無效則會把上次服務端響應的最后修改時間作為 If-Modified-Since 的值發送給服務器進行判斷，如果文件沒有改變，服務器采用 304-Not Modified做響應頭和一個為空的響應體。客戶端收到304響應，就可以使用緩存的文件版本了。

為什么客戶端無效，還要發送HTTP請求來判斷文件是否修改呢？

如果緩存資源有效那就是直接來讀取客戶端緩存，不需要發送HTTP請求。但有一些情況就需注意，比如當用戶按F5或者點擊Refresh按鈕的時候就算對于有Expires的URI，一樣也會發一個HTTP請求出去，所以就需要通過Last-Modified來判斷。

而且客戶端和服務端的時間可能不一樣，這樣就會導致客戶端已過期，但服務端并沒有。如果有判斷機制，那么響應就會減少響應體的數據發送。或者客戶端只是單純的 Expires 過期，但資源并沒改變，這時就需要檢查文件是否有變化。

HTTP 1.1

HTTP 1.1有了較大的增強，緩存系統被形式化了，引入了實體標簽 **e-tag 和 Cache-Control。

e-tag 是文件或對象的唯一標識。每次請求攜帶e-tage參數進行訪問，文件是否被更新。
Cache-Control：相對過期，從客戶端收到響應時間時開始計算，多少秒后緩存會過期。具體字段信息如下： max-age：用來設置資源（representations）可以被緩存多長時間，單位為秒； s-maxage：和max-age是一樣的，不過它只針對代理服務器緩存而言；　　- public：指示響應可被任何緩存區緩存； private：只能針對個人用戶，而不能被代理服務器緩存； no-cache：強制客戶端直接向服務器發送請求,也就是說每次請求都必須向服務器發送。服務器接收到請求，判斷資源是否變更，否則返回新內容，否則返回304。 no-store：禁止一切緩存（這個是響應不被緩存的意思）
If-None-Match：第一次發送etag字段響應給客戶端后，下次請求客戶端會同時發送一個If-None-Match來判斷數據是否發送變化，而它的值就是Etag的值

以Web瀏覽器使用 e-tag 為例，如下圖所示。

在配置了 Last-Modified/ETag 的情況下，瀏覽器再次訪問統一URI的資源時，還是會發送請求到服務器詢問文件是否已經修改，如果沒有，服務器會生成304-Not Modified應答和一個空的響應體給瀏覽器，瀏覽器則直接從本地緩存取數據；如果數據有變化，就將整個數據重新發給瀏覽器。

匯總

Last-Modified/ETag 與 Cache-Control/Expires的作用是不一樣的。前者是每次詢問實體版本是否有變化，后者是直接檢查本地的緩存還在有效的時間范圍內，如果在就不會發送任何請求。

兩者一起使用時，Cache-Control/Expires的優先級要高于Last-Modified/ETag。

當本地副本根據 Cache-Control/Expires 判斷是否還在有效期內，如果不在，則會再次發送請求去服務器詢問修改時間（Last-Modified）或實體標識（e-tag）。

Cache-Control與Expires的功能一致，都是指當前資源的有效期，控制瀏覽器是直接從瀏覽器緩存取數據還是重新發請求到服務器取數據。只不過Cache-Control的選擇更多，設置更細致，如果同時設置的話，其優先級高于Expires。

一般情況下，使用 Cache-Control/Expires 會配合 Last-Modified/ETag 一起使用，因為即使服務器設置緩存時間，當用戶點擊刷新按鈕時，瀏覽器會忽略緩存繼續向服務器發送請求，這時Last-Modified/ETag將能夠很好利用服務端的返回碼304，從而減少響應開銷。

通過在HTML頁面的節點中加入meta標簽，可告訴瀏覽器當前頁面不被緩存，每次訪問都需要去服務器拉取。代碼如下：

<META HTTP-EQUIV="Pragma" CONTENT="no-cache">

只不過，只有部分瀏覽器才支持這一用法，而且一般 緩存代理服務器都不支持，因為代理本身不解析 HTML 的內容。瀏覽器緩存能夠極大地提升終端用戶的體驗，那么，用戶在使用瀏覽器的時候，會有各種操作，如輸入地址后回車、按F5刷新等等，這些行為對緩存的影響如下所示。

APP端緩存

盡管混合編程（hybrid programming）已成為時尚，吵在尖端，但移動互聯網目前還是原生應用（APP）的天下。無論大小型APP，靈活的緩存不僅大大減輕了服務器的壓力，而且會因更快速的用戶體驗而方便用戶。 如何把APP 緩存對于業務組件透明，以及APP緩存數據的及時更新，是APP緩存能否成功應用起來的關鍵。

組件透明是什么？

即組件對調用者來說沒有什么影響，也不需要維護。開箱即用。

APP緩存可使用哪些緩存？

APP可以將內容緩存在 內存、文件或本地數據庫（例如SQLite）中，但基于 內存的緩存 要謹慎使用。

本地庫操作

APP使用數據庫緩存的方法：

在下載完數據文件后，把文件的相關信息(如URL、路徑、下載時間、過期時間等)存放到數據庫.
等下次請求下載的時候，根據URL先從數據庫中查詢，如果查詢到當前時間并未過期，就根據路徑讀取本地文件，實現緩存的效果。

優點：方法具有靈活存放文件的屬性，進而提供了很大的擴展性，可以為其他的功能提供良好的支持。
缺點：信息存儲過多，存儲容量會降低。所以要根據業務選擇合適主要的信息存儲

注意數據庫緩存的清理機制 。

文件操作

對APP中的某些界面，可以采用文件緩存的方法。這種方法使用文件操作的相關API得到文件的最后修改時間，與當前時間判斷是否過期，從而實現緩存效果。

但需要注意的是，不同類型文件的緩存時間不一樣。比如：
文件類型：

圖片文件的內容是相對不變的，直到最終被清理掉，APP可以永遠讀取緩存中的圖片內容。
配置文件中的內容是可能更新的，需要設置一個可接受的緩存時間。同時，不同環境下的緩存時間標準也是不一樣的。

網絡環境：

WiFi網絡環境下，緩存時間可以設置短一點，一是網速較快，二是不產生流量費。
移動數據流量環境下，緩存時間可以設置長一點，節省流量，而且用戶體驗也更好。

在IOS開發中，SDWebImage是一個很棒的圖片緩存框架，主要類組成的結構如下所示。

SDWebImage 是個比較大的類庫，提供一個UIImageView的類以支持遠程加載來自網絡的圖片，具有緩存管理、異步下載、同一個URL下載次數控制和優化等特征。使用時，只需要在頭文件中引入 #import"UIImageView+WebCache.h" 即可調用異步加載圖片方法：

  (void)setImageWithURL:(NSURL *)url placeholderImage:(UIImage *)placeholder options:(SDWebImageOptions)options;

URL是圖片的地址

placeholderImage是網絡圖片在尚未加載成功時顯示的圖像
SDWebImageOptions是相關選項。

默認情況下，SDWebImage會忽略Header中的緩存設置，將圖片以URL為key進行保存，URL與圖片是一個映射關系。在APP請求同一個URL時，SDWebImage會從緩存中取得圖片。將第三個參數設置為SDWebImageRefreshCached就可以實現圖片更新操作，例如：

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中有兩種緩存

磁盤緩存
內存緩存

框架都提供了相應的清理方法：

[[[SDWebImageManager sharedManager] imageCache] clearDisk]; 
[[[SDWebImageManager sharedManager] imageCache] clearMemory];

要注意的是，在iOS7中，緩存機制做了修改，使用上述兩個方法只清除了SDWebImage的緩存，沒有清除系統的緩存，所以可以在清除緩存的代碼中添加以下代碼：

[[NSURLCache sharedURLCache] removeAllCachedResponses];

最后：

緩存根據存在方式有系統、硬件、軟件三類。
軟件根據場景客戶端、網絡、分布式緩存
用戶體驗**：即用戶在使用一個產品或系統之前、使用期間和使用之后的全部感受。
系統性能指標有響應時間、延遲時間、吞吐量，并發用戶數和資源利用率等幾方面
網站架構演講，經歷起步、發展、中期、高速增長、后期
客戶端緩存分為頁面緩存、瀏覽器緩存、APP緩存

以上就是本文分享，但內容未完，這還是開胃小菜。若有幫助，歡迎關注、分享+收藏額

需獲取本系列總結大綱直接后臺私信回復“分布式緩存”即可免費領取！！！

絮絮叨叨

其實，大綱很早就寫好了，但對里面內容的呈現方式，細節原理就一直不知道如何撰寫才能達到明朗的效果。

這文章花了我非常多時間。哎，菜就是菜，吒吒輝我也不找借口了。。。吒就是吒

還是太弱

如果大家在閱讀過程中，發現了不理解或有錯誤的地方，歡迎跟在底部留言，你們的每一條留言，吒吒輝都會回復。

日日操夜夜添-日日操影院-日日草夜夜操-日日干干-精品一区二区三区波多野结衣-精品一区二区三区高清免费不卡

緩存只會用！緩存架構沒聽過？分布式多級緩存大瓶裝，你拎包帶走絮叨什么是緩存？什么是多級緩存架構？為什么使用多級緩存架構？聊聊用戶體驗什么是用戶體驗？影響用戶體驗的因素關于系統的性能響應時間吞吐量并發用

絮叨