隨著互聯網業務的快速迭代以及用戶量激增，應用架構需要不斷調整甚至重構以適應這種業務的快速發展。當數據量迅速增長，業務邏輯越復雜，服務鏈路不斷增加等等一系列問題，會導致RT過長，服務性能需要逐漸提升以滿足更優的用戶體驗。在優化系統架構時通常的所用的兩種方式scale up以及scale out，scale out就是通常所說的水平擴展，將應用服務設計成無狀態性，可以方便水平擴展通過增加硬件的方式分解訪問壓力。而scale up則是將單個服務鏈路性能提升，以提升QPS以及系統的吞吐量。在追求更優的性能時，大多數業務場景是讀多寫少的情況，一般會通過引入緩存的方式解決。

1. What——什么是緩存？

關于緩存的定義，在wiki中為：

a collection of data duplicating original values stored elsewhere on a computer, usually for easier access.

簡單理解就是保存在計算機設備中的一個數據副本，以便于后續能夠進行快速訪問。

從定義上可以看出所謂緩存一定是針對已有數據的一個副本存在，也可以看出緩存的使用是為了解決快速訪問數據（讀數據）的場景。在現有的互聯網應用中，緩存的使用是一種能夠提升服務快速響應的關鍵技術，也是產品經理無暇顧及的非功能需求，需要在設計技術方案時對業務場景，具有一定的前瞻性評估后，決定在技術架構中是否需要引入緩存解決這種這種非功能需求。

緩存在計算機領域中實際案例存在很多，比如CPU的緩存是為了解決CPU的運算速度和內存的讀取數據不平衡的問題，CPU的運算速度遠快與內存的讀寫速度，為了降低CPU等待數據讀寫的時間，在CPU中引入L1/L2/L3多級緩存。

再比如Linux中的文件緩存，實際上我們在編程時，會談論到數據的內存地址，但是我們接觸的都是虛擬地址而不是真實的物理地址，計算機中的內存管理單元（MMU）和頁表會將虛擬地址轉換成物理地址。在計算機硬件領域中就已有很多關于緩存的應用案例，實際上在軟件架構中關于緩存的設計會借鑒于很多傳統且成熟的計算機硬件緩存設計的思想。

2. Why——為什么需要使用緩存？

軟件服務能夠得到用戶的信賴，并將產品的價值帶給用戶，能夠解決目標用戶的痛點問題這是決定用戶會不會一開始決定使用，也就是《增長黑客》中提到了產品能夠帶來給用戶“啊哈時刻”，而決定用戶會不會高頻使用以及持續使用，用戶體驗則是被認為是軟件產品提升用戶黏性的關鍵影響因素。

2.1 什么是用戶體驗

用戶體驗被專業定義和推廣需要推廣到20世紀90年代，由Donald Norman布道推廣。用戶體驗在人機交互領域上受到了重視，并一度和傳統的三大可用性指標（即效率、效益以及基本滿意度）不相上下。

ISO 9241-210標準將用戶體驗官方定義為：人們對正在使用或者期待使用的產品、系統或者服務的認知印象和回應?？梢钥闯鲇脩趔w驗是用戶的對軟件產品的主觀感受，具體包含了用戶在使用之前、使用中以及使用后的情感、喜好、認知印象、心理反應以及情緒表達等等多種主觀感受，每個用戶對產品的主觀感受的視角不同，關注點不同，也就導致軟件產品讓大多數用戶都能夠獲得很好的用戶體驗本身就是一件很有挑戰性的事情。

在業界大多數，將用戶體驗分為三類：使用者狀態、軟件產品的系統性能以及環境，使用者狀態以及環境（使用者環境以及產品在同類產品中的產品大環境）這兩個因素需要交互設計和用研等多個專業領域同學去攻克，軟件開發者則需要解決系統性能的問題。對用戶而言，最基本的需求就是在使用軟件服務時，軟件產品提供服務內容的及時性，也就是通常所說的在使用過程中持續的Loading（轉菊花）一定會導致用戶體驗很差，內容的及時性也是系統性能的最低要求。

而系統性能的問題，是產品經理無暇顧及的點，也是非功能性需求，需要開發者去花心思去思考的地方。評估系統性能的指標有很多，在以提升用戶體驗為前提的情況下，我們需要著重關注的性能指標有哪些呢？

2.2 常見的性能指標

在設計軟件架構時需要關注的幾個常見指標：響應時間、延遲時間、吞吐量、并發用戶數和資源利用率。

1）系統響應時間 ：響應時間是指系統對用戶請求做出響應的時間，不同的功能的鏈路長短不同，并且同一功能在不同數據量等這些情況都會導致響應時間的不同。因此，在衡量系統響應時間時，通常會關注軟件產品所有功能的平均響應時間以及最大響應時間。

2）延遲時間 ：在討論系統響應時間時，更細粒度的劃分可以劃分為：

• 客戶端在接受數據進行渲染的內容“呈現時間”；

• 服務端在接受用戶請求發送至服務端以及服務端將數據返回到客戶端這兩個過程中涉及到的：網絡傳輸時間以及應用延遲時間。應用延遲時間即是服務端在執行整個服務鏈路時所花費的時間，也是性能優化首要降低的就是這個時間。
  

3）吞吐量 ：吞吐量指的是單位時間內能夠處理請求的數量，對于無并發的應用來說，吞吐量和請求響應時間成反比，服務延遲更長則系統吞吐量更低。

4）并發用戶數 ：并發用戶數指的是系統能夠同時承載正常使用系統功能的用戶數，相較于吞吐量，這個指標更為籠統但是對于非軟件領域的人來說更容易理解。

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

2.3 緩存帶來的優勢

在追求更優的優化體驗時，客觀的來說需要不斷提升以上這些性能指標，不斷逼近系統體驗的最優解。緩存到底具有什么樣的優勢，值得我們花費很大的精力去設計一套能很好的適應現在的業務場景的緩存結構呢？

1）極大的提升軟件用戶體驗?

軟件產品主要圍繞兩個核心問題，一是解決目標用戶的痛點問題，二是提升產品黏性。在提供軟件服務時，抽象的來看是解決數據在整個鏈路上的流轉問題，如何讓數據流轉更加高效、更加順暢是在實現時著重關注的地方，事實上，無論是瀏覽器、負載均衡、應用服務器還是數據庫等等各個環節都會應用到緩存，當數據離用戶“更近”，比如數據副本在客戶端上，也就意味著請求能夠很快的進行響應，相應的給用戶進行數據呈現的耗時就更短?，F如今用戶爸爸們“日理萬機”，如果一個軟件產品不能在很短時間就獲取用戶的注意力，很大可能性就意味著失敗。因此，使用緩存能夠讓用戶從主觀上獲取更優的用戶體驗。

2）提升吞吐量?

試想，如果在服務鏈路上，請求能夠在緩存中獲取服務數據的話，也就意味著很多數據并不需要從源應用服務器進行獲取，降低了源服務器網絡傳輸的頻率，在一定IDC帶寬下，系統能夠降低網絡傳輸時間以及應用延遲時間，從而支撐更多的系統訪問以提升系統整體吞吐量以及并發用戶數，硬件的使用效率也會明顯提升。

從實際場景下，在系統性能優化時大概率會優先選擇使用緩存進行系統優化，也是一種被證明有效的手段，緩存也被認為是一種“空間換時間”的藝術。

3. Where——緩存存在鏈路中的哪些地方？

3.1 緩存分類

從一個請求到最終獲取響應，會經過很多環節，緩存可以幾乎存在整個鏈路的每個節點。緩存按照不同的維度可以有如下分類：

1）緩存所處鏈路節點的位置：

• 客戶端緩存
  

• 網絡緩存

• 服務端緩存

2）緩存架構部署方式：

• 單機緩存
  

• 緩存集群

• 分布式緩存

3）緩存的內存區域

• 本地緩存/進程內緩存

• 進程間緩存

• 遠程緩存

按照緩存在服務鏈路上的位置來劃分，可以系統性的梳理下緩存的不同應用。

3.2 客戶端緩存

客戶端緩存是離用戶“最近”的一種存儲介質，經常和網絡測和服務端緩存一起配合使用，常見的客戶端緩存有如下幾種：

1）頁面緩存：頁面緩存是指將靜態頁面獲取頁面中的部分元素緩存到本地，以便下次請求不需要重復資源文件，h5很好的支持的離線緩存的功能，具體實現可通過頁面指定manifest文件，當瀏覽器訪問一個帶有manifest屬性的文件時，會先從應用緩存中獲取加載頁面的資源文件，并通過檢查機制處理緩存更新的問題。

2）瀏覽器緩存：瀏覽器緩存通常會專門開辟內存空間以存儲資源副本，當用戶后退或者返回上一步操作時可以通過瀏覽器緩存快速的獲取數據，在HTTP 1.1中通過引入e-tag標簽并結合expire、cache-control兩個特性能夠很好的支持瀏覽器緩存，關于瀏覽器緩存更為細節的知識可以查看該文章。

3）APP緩存：APP可以將內容緩存到內存或者本地數據庫中，例如在一些開源的圖片庫中都具備緩存的技術特性，當圖片等資源文件從遠程服務器獲取后會進行緩存，以便下一次不再進行重復請求，并可以減少用戶的流量費用。

客戶端緩存是前端性能優化的一個重要方向，畢竟客戶端是距離“用戶”最近的地方，是一個可以充分挖掘優化潛力的地方。

3.3 網絡緩存

網絡緩存位于客戶端以及服務端中間，通過通過代理的方式解決數據請求的響應，降低數據請求的回源率。通常具有如下幾種形式的網路緩存：

1）web代理緩存：常見的代理形式分為分為：正向代理、反向代理以及透明代理。web代理緩存通常是指正向代理，會將資源文件和熱點數據放在代理服務器上，當新的請求到來時，如果在代理服務器上能獲取數據，則不需要重復請求到應用服務器上；

2）邊緣緩存：和正向代理一樣，反向代理同樣可以用于緩存，例如nginx就提供了緩存的功能。進一步，如果這些反向代理服務器能夠做到和用戶請求來自同一個網絡，那么獲取資源的速度進一步提升，這類的反向代理服務器可以稱之為邊緣緩存。常見的邊緣緩存就是CDN（Content Delivery Network），可以將圖片等靜態資源文件放到CDN上。

3.4 服務端緩存

服務端緩存是后端開發中進行性能優化的發力點，常見的后端性能優化也是通過引入緩存來進行解決，常見的有數據庫的查詢緩存、緩存框架以及引入應用級緩存。

★? 3.4.1 數據庫查詢緩存

例如，MySQL的緩存機制是通過將SELECT語句以及相應的ResultSet進行緩存，當后續接受到SELECT請求后，如果MySQL已經開啟了Query Cache功能，會將SELECT語句以字符串的方式進行hash，然后去從緩存中進行查詢，如果查詢出數據，則直接進行返回，省去了后續的優化器以及存儲引擎IO的操作，能夠極大的提升響應時效。如何優化Query Cache需要從如下幾個指標上進行考慮：

• query_cache_size：設置能夠緩存ResultSet的內存區域大小

• query_cache_type：表示使用緩存的場景。0表示任何場景下都不使用Query Cache，1表示顯式指定不使用Query Cache的查詢都可以使用，2（DEMAND）表示只有明確指示使用Query Cache才會生效；

• Qcache hits：表示多少次查詢命中Query Cache

• Qcache inserts：表示多少次沒有命中Query Cache而插入數據

• Qcahce lowmem prunes：表示多少條Query引入空間不足而被清除

• Qcache free memory：表示剩余內存大小

• Qcache free blocks：該值很大表示內存碎片很多，需要及時清理

在進行Qcache優化時，可以對以上指標綜合進行分析，比如了解Qcache的緩存命中率 = Qcache hits/ Qcache hits + Qcache inserts，來判斷當前Qcache的效率。也可以結合Qcahce lowmem prunes、Qcache free memory以及Qcache free blocks來判斷當前Qcache的內存使用效率。

另外，如果使用Innodb存儲引擎的話，也需要著重關注innodb_buffer_pool_size參數，該參數決定了innodb的索引以及數據是否有足夠大的空間放入到緩存中。table_cache決定了能夠緩存表的最大數量，也是需要關注的一個參數。

★? 3.4.2 緩存框架

在功能開發時，會常用提供緩存特性的緩存框架或者實現緩存功能的類庫來高效的完成開發，常見的緩存框架有Ehcache、Guava等，這些緩存框架配置簡單，能夠簡單靈活的使用。這些開源的緩存框架不僅支持單機的本地緩存還能配置集群的方式達到靈活伸縮。

★? 3.4.3 應用級緩存

當緩存框架不能滿足需求的時候，就需要引入應用級緩存，比如Redis、MongoDB等NoSQL數據庫，應用級緩存具備高可用性以及伸縮性的分布式架構能夠支撐業務需求，當然，做好一款應用級緩存產品其中的挑戰也是巨大。

4. When——什么時候需要使用緩存？

緩存不是架構設計的必選項，也不是業務開發中的必要功能點，只有在業務出現性能瓶頸，進行優化性能的時候才需要考慮使用緩存來提升系統性能。也不是所有的業務場景都適合使用緩存，讀多寫少且數據時效要求越低的場景越適合使用緩存，緩存并不是所有性能問題的靈丹妙藥，如果濫用緩存反而會成為毒藥，并且會引入維護緩存的操作成本，使得系統復雜度更高不利于維護。

另外把緩存當做存儲來使用是一件極其致命的做法，這種錯誤的認識，將緩存引入系統的那一刻起就意味著已經讓系統走上了危險的局面，對緩存的使用邊界要有深刻的理解，才能盡可能保證做出引入緩存才是一個正確的決定。

在進行緩存結構設計的時候，需要考慮的點有很多：

1）業務流量量級以及應用規模：對于低并發低流量的應用而言，引入緩存并不會帶來性能的顯著提升，反而會帶來應用的復雜度以及極高的運維成本。也不是任何數據都需要使用緩存，比如圖片視頻等文件使用分布式文件系統更合適而不是緩存。因此，在引入緩存前，需要對當前業務的流量進行評估，在高并發大流量的業務場景中引入緩存相對而言收益會更高；

2）緩存應用的選擇：緩存應用有很多如Redis、Memcached以及tair等等，針對每一種分布式緩存應用的優缺點以及適用范圍、內存效率、運維成本甚至團隊開發人員的知識結構都需要了解，才能做好技術選型；

3）緩存影響因素的正確評估：在引入緩存前，需要著重評估value大小、緩存內存空間、峰值QPS、過期時間、緩存命中率、讀寫更新策略、key值分布路由策略、過期策略以及數據一致性方案等等多個因素，要做到心中有數；

4）緩存高可用架構：分布式緩存要高可用，這也是分布式系統追求的三高指標中的一個，緩存的集群設計，主從同步方案的設計等等，只有緩存足夠可靠，才能服務于業務系統，為業務帶來價值；

5）完善的監控平臺：當緩存投入生產環境后，需要有一套監控系統能夠顯式的觀測緩存系統的運行情況，才能更早的發現問題，同時對于預估不足的非預期熱點數據，也需要熱點發現系統去解決非預期的熱點數據緩存問題。

6）緩存最近原則：將緩存數據放在離用戶最近的地方，無疑會極大的提升響應的速度，這也是多級緩存設計的核心思想。

6.參考資料

《深入分布式緩存》

https://book.douban.com/subject/27602483/?spm=ata.13261165.0.0.1fbe62a58KTCCF

緩存穿透、緩存擊穿以及緩存雪崩問題探討：

1.https://www.cnblogs.com/Leo_wl/p/9062029.html?spm=ata.13261165.0.0.1fbe62a58KTCCF

2.https://blog.csdn.net/zeb_perfect/article/details/54135506?spm=ata.13261165.0.0.1fbe62a58KTCCF

3.https://www.cnblogs.com/Leo_wl/p/9062029.html?spm=ata.13261165.0.0.1fbe62a58KTCCF#_label0_0

緩存更新策略：

1.https://www.jianshu.com/p/8950c52ce53b?spm=ata.13261165.0.0.3d1462a5BuyJzs

2.https://www.jianshu.com/p/22c7e9ab5d15?spm=ata.13261165.0.0.3d1462a5BuyJzs

3.https://www.cnblogs.com/rjzheng/p/9041659.html?spm=ata.13261165.0.0.3d1462a5BuyJzs

4.https://www.jianshu.com/p/8950c52ce53b?spm=ata.13261165.0.0.3d1462a5BuyJzs

數據最終一致性：

1.https://blog.kido.site/2018/11/24/db-and-cache-preface/?spm=ata.13261165.0.0.3d1462a5BuyJzs

2.https://msd.misuland.com/pd/3255817997595443436?spm=ata.13261165.0.0.3d1462a5BuyJzs

3.https://blog.51cto.com/14214194/2411931?spm=ata.13261165.0.0.3d1462a5BuyJzs

4.https://www.cnblogs.com/pomer-huang/p/8998623.html?spm=ata.13261165.0.0.3d1462a5BuyJzs

緩存設計：

1.https://blog.csdn.net/zjttlance/article/details/80234341?spm=ata.13261165.0.0.3d1462a5BuyJzs

2.https://stor.51cto.com/art/201908/600603.htm?spm=ata.13261165.0.0.3d1462a5BuyJzs

3.https://yq.aliyun.com/articles/652472?spm=ata.13261165.0.0.3d1462a5BuyJzs&utm_content=m_1000018600

4.https://blog.csdn.net/ruanchengmin/article/details/79210632?spm=ata.13261165.0.0.3d1462a5BuyJzs

END

有道無術，術可成；有術無道，止于術

歡迎大家關注Java之道公眾號

好文章，我在看??

總結

以上是生活随笔為你收集整理的阿里工程师是如何系统化地总结缓存相关知识的的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。