There are only two hard things in Computer Science: cache invalidation and naming things.

計算機科學中有兩件難事：緩存失效和命名

– Phil Karlton

From Martin Fowler : TwoHardThings

緩存系統(tǒng)一定程度上極大提升系統(tǒng)并發(fā)能力，但同樣也增加額外技術(shù)考慮因素，下面針對緩存系統(tǒng)設(shè)計與使用中面臨的常見問題展開。

• 緩存應(yīng)用的典型場景
• 緩存雪崩
• 緩存穿透
• 緩存更新與數(shù)據(jù)一致性

緩存應(yīng)用的典型場景

請求->緩存->***緩存則返回數(shù)據(jù)->無緩存則讀取原始數(shù)據(jù)源

緩存定位 ：前置數(shù)據(jù)加載，避免數(shù)據(jù)回源，提供高性能、高并發(fā)的數(shù)據(jù)讀取能力；只有未***緩存時才進行數(shù)據(jù)回源，極大減輕原始數(shù)據(jù)讀取的壓力

緩存分類 ：按緩存系統(tǒng)所處位置不同，分為本地緩存、分布式緩存

• 本地緩存：內(nèi)存級緩存、文件級緩存，內(nèi)存級緩存優(yōu)勢在于本地內(nèi)存I/O、高性能(單次內(nèi)存尋址100ns)，缺點在于空間有限，無法多端數(shù)據(jù)同步，此類方案有PHP的Opcache/Yac, Java中Encache/GuavaCache/SpringCache等；文件級緩存依賴磁盤I/O實現(xiàn)緩存作用，受機械磁盤尋道性能限制(單次磁盤讀取時間10ms左右)，或考慮固態(tài)硬盤/Raid優(yōu)化方案，較少使用
• 分布式緩存：Memcached、Redis等，分布式系統(tǒng)解決緩存容量問題，具備持續(xù)擴容能力，但不可避免一次網(wǎng)絡(luò)I/O請求

本文主要討論 分布式緩存 系統(tǒng)設(shè)計與使用中面臨的問題。

緩存雪崩

定義： 緩存雪崩是指緩存系統(tǒng)失效，導致大量請求同時進行數(shù)據(jù)回源，導致數(shù)據(jù)源壓力驟增而崩潰 。兩種情況會導致此問題：1、多個緩存數(shù)據(jù)同時失效；2、緩存系統(tǒng)崩潰

緩存同時失效

• 在大量緩存同時失效的情況下，請求回源，導致數(shù)據(jù)源請求暴增而崩潰，系統(tǒng)全局不可用
• 緩存時間設(shè)置原則：根據(jù) 緩存數(shù)據(jù)訪問規(guī)律和緩存數(shù)據(jù)不一致的敏感性 要求來選擇緩存時間
• 緩存數(shù)據(jù)訪問規(guī)律：如不同緩存數(shù)據(jù)訪問無規(guī)律或相對離散，則不會存在這些緩存數(shù)據(jù)同時失效的情況；如 緩存數(shù)據(jù)為批量寫入 (定時任務(wù)預熱)，應(yīng)考慮將 緩存時間離散化 ，避免同時失效的情況下大量回源請求
• 緩存數(shù)據(jù)不一致的敏感性：不同應(yīng)用場景下對緩存數(shù)據(jù)的一致性要求不同，緩存時間的設(shè)置視情況而定
• 這里也涉及到緩存更新策略問題，錯誤的更新策略可能會先刪除緩存，再設(shè)置緩存，此時間差范圍內(nèi)的請求會進行回源，會導致此問題

如何避免應(yīng)考慮： 緩存失效時間離散化

緩存系統(tǒng)故障

緩存系統(tǒng)整體故障，則整個緩存系統(tǒng)不可用，大量回源請求，且由于緩存系統(tǒng)故障無法回寫緩存，導致無法快速恢復。

一句老話：為解決一個問題，引入新的解決方案，同時也必然引入新的問題。

這也是緩存系統(tǒng)的引入，在解決高性能、高并發(fā)的同時，引入了新的故障點。

考慮此問題，應(yīng)從事前、事故中、事后不同階段考慮：

• 事前：增加緩存系統(tǒng) 高可用方案設(shè)計 ，避免出現(xiàn)系統(tǒng)性故障
• 事故中：

  熔斷限流機制
  

• 事后：緩存 數(shù)據(jù)持久化 ，在故障后 快速恢復 緩存系統(tǒng)

緩存穿透

定義： 緩存穿透是指訪問不存在數(shù)據(jù)，從而繞過緩存，直取數(shù)據(jù)源（大量數(shù)據(jù)源讀取操作）

解決緩存穿透的思路：

• 不存在資源訪問時，在緩存系統(tǒng)設(shè)置空值來攔截
  • 優(yōu)點：實現(xiàn)簡單
  • 問題：大量非法請求時，緩存系統(tǒng)被填充大量非法值 
     

  

• 根據(jù)資源設(shè)置攔截機制（布隆過濾器bloomfilter或壓縮filter過濾有效資源，如有效用戶id等；也可以全局保存有效資源摘要，專用過濾、防穿透）
  • 優(yōu)點：緩存系統(tǒng)空間利用較好
  • 問題：過濾器實現(xiàn)機制和數(shù)據(jù)一致性要求 
     

  

緩存更新與數(shù)據(jù)一致性

緩存系統(tǒng)數(shù)據(jù)的更新策略是需要專門開題來說的，建議閱讀 左耳朵耗子：緩存更新的套路 系統(tǒng)了解，這里只根據(jù)實際經(jīng)驗給出在不同一致性要求下的建議。

一種常見緩存更新策略（此方案有問題）：

• 讀操作：***緩存則返回，無緩存則取回源數(shù)據(jù)，寫緩存
• 寫操作：先刪除緩存，再更新數(shù)據(jù)源

問題場景：讀寫并發(fā)的場景下先刪緩存操作可能導致臟數(shù)據(jù)入緩存

• 寫操作：刪除緩存
• 讀操作：無緩存則取回源數(shù)據(jù)（舊數(shù)據(jù)），回寫緩存（此時緩存中為舊數(shù)據(jù)）
• 寫操作：更新數(shù)據(jù)源
• 此時緩存數(shù)據(jù)不一致：緩存中為舊數(shù)據(jù)，數(shù)據(jù)源為新數(shù)據(jù)，出現(xiàn)緩存舊數(shù)據(jù)問題

幾種更新緩存的策略：

• Cache Aside Pattern：緩存失效時回源取數(shù)據(jù)，更新緩存；***緩存時，返回緩存數(shù)據(jù)；先數(shù)據(jù)源更新后，再失效緩存（由等待下次讀取來回寫緩存）
  • 優(yōu)勢：無緩存舊數(shù)據(jù)問題、緩存系統(tǒng)維護簡單、Facebook推薦方案
  • 問題：無法絕對杜絕并發(fā)讀寫問題
    • 緩存過期的背景下，讀操作回源取數(shù)據(jù)（此時為舊數(shù)據(jù)）
    • 寫操作：更新數(shù)據(jù)源，失效緩存
    • 讀操作：將回源數(shù)據(jù)（舊數(shù)據(jù)）寫緩存，出現(xiàn)緩存數(shù)據(jù)不一致問題
    • 這種問題出現(xiàn)概率極低，幾點要求：緩存已過期、并發(fā)讀寫、讀數(shù)據(jù)比寫數(shù)據(jù)快、但讀操作更新緩存比寫操作失效緩存慢（也就是說寫操作的行為需完全發(fā)生在讀操作兩步之間），一般而言讀操作（讀庫+更新緩存）時長要小于寫操作（更新數(shù)據(jù)源+失效緩存），所以認為這種并發(fā)問題概率較低
    • 是否可進一步解決此問題：增加鎖機制，解決并發(fā)問題
• Read Through Pattern：更新數(shù)據(jù)源由緩存系統(tǒng)操作

  讀取數(shù)據(jù)
  

• Write Through Pattern：更新數(shù)據(jù)源由緩存系統(tǒng)操作

  寫數(shù)據(jù)
  Read Through
  

• Write Behind Caching Pattern：又稱 Write Back
  • 一句話總結(jié)：更新數(shù)據(jù)時，只更新緩存，不更新數(shù)據(jù)源（緩存 異步批量 更新數(shù)據(jù)源）
  • 優(yōu)勢：
    • 更新緩存為內(nèi)存操作，讀寫I/O非常高
    • 異步批量更新數(shù)據(jù)源，合并多個操作
  • 問題：
    • 緩存不滿足強一致性要求
    • 強一致性和高性能的沖突 、 高可用和高性能的沖突 終究會使Trade-Off
    • 實現(xiàn)復雜，需跟蹤哪些Cache更新，成本較高

總體來說，不同方案在不同場景下是有各自優(yōu)劣的，技術(shù)選型、架構(gòu)設(shè)計應(yīng)根據(jù)實際場景取舍，并對選擇方案的利弊有足夠且深入理解。

一般而言，推薦 Cache Aside Pattern 方案，容忍較小概率的不一致（同時也可以增加鎖機制解決此低概率并發(fā)問題），簡化緩存系統(tǒng)復雜度。