存是個老生長談的問題，對于前端工程師來講更是我們的必修課。或許很多人會說我的項目并沒有問題，根本不需要聊什么緩存。如果真的是這樣，只能證明你前端道路才剛剛開始。

背景

小郭今天分享緩存的原因在于：公司的一個核心APP中嵌入了SPA，而且應用核心都分布在SPA中，功能復雜且重。問題出現(xiàn)了：應用核心頁面打開一直處于加載狀態(tài)，排除掉弱網(wǎng)環(huán)境的原因，重點就在于沒有緩存，每次進入頁面都需要重載DOM和數(shù)據(jù)，拖慢頁面打開速度。

那應該處理緩存問題呢？接下來小郭從三個方向來講解。

瀏覽器緩存策略

在了解瀏覽器緩存前，我們需要先了解一下相關的概念：cache-control，expires，last-Modified，ETag。

瀏覽器通過請求頭實現(xiàn)緩存，關鍵的請求頭有cache-control，expires，last-Modified，ETag等。我們從時間和空間兩個角度來看瀏覽器緩存。

時間

瀏覽器發(fā)送第一次請求：不緩存，服務端根據(jù)設定的緩存策略返回相應的header，如：cache-control，expires，last-Modified，ETag。

瀏覽器發(fā)送第二次請求：

• 強緩存策略：不需要和服務端通信就決定是否使用緩存，cache-control優(yōu)先級大于expires① 有cache-control且不過期，返回本地磁盤緩存，狀態(tài)值200；② 有expires且不過期，返回本地磁盤緩存，狀態(tài)值200。
• 協(xié)商緩存策略：需要和服務端通信決定是否用緩存，Etag優(yōu)先級大于last-Modified。① 有Etag，請求頭添加If-None-Match，值就是上次返回的Etag值，然后發(fā)送給服務端。服務端對比If-None-Match與現(xiàn)有的Etag值是否一樣；一樣的話只返回header，狀態(tài)碼304，瀏覽器從本地磁盤獲取緩存信息；不一樣走正常流程，返回header+body，狀態(tài)碼200；② 有l(wèi)ast-Modified，添加請求頭If-Modified-Since，值是上次返回的last-Modified，然后發(fā)送給服務端。服務端對比If-Modified-Since與現(xiàn)有的是否一樣；一樣的話返回只返回header，狀態(tài)碼304，瀏覽器從本地磁盤獲取緩存信息；不一樣走正常流程，返回header+body，狀態(tài)碼200
• 無緩存

空間

• 瀏覽器和服務端：服務端需要決定使用哪種緩存策略并在響應頭返回；前端不需要設置，是瀏覽器本身機制。
• html和靜態(tài)資源：通常html不設置緩存，因為其它資源的入口都是html文件；靜態(tài)資源（js，css，圖片等）會設置緩存

部署時緩存的問題

如果緩存就按理論上設置，那就太簡單了。在實際應用有個嚴重的問題，我們不僅要緩存代碼，還需要更新代碼。如果靜態(tài)資源名字不變，怎么讓瀏覽器即能緩存又能在有新代碼時更新。最簡單的解決方式就是靜態(tài)資源路徑添加一個版本值，版本不變就走緩存策略，版本變了就加載新資源。如下：

<script src="xx/xx.js?v=24334452"></script>

然而這種處理方式在部署時有問題。

解決方法：靜態(tài)資源和頁面是分開部署

• 先部署頁面再部署靜態(tài)資源，會出現(xiàn)用戶訪問到舊的資源
• 先部署靜態(tài)資源再部署頁面，會出現(xiàn)沒有緩存用戶加載到新資源而報錯

這些問題的本質是以上的部署方式是“覆蓋式發(fā)布”，解決方式是“非覆蓋式發(fā)布”。即用靜態(tài)資源的文件摘要信息給文件命名，這樣每次更新資源不會覆蓋原來的資源，先將資源發(fā)布上去。這時候存在兩種資源，用戶用舊頁面訪問舊資源，然后再更新頁面，用戶變成新頁面訪問新資源，就能做到無縫切換。簡單來說就是給靜態(tài)文件名加hash值。

那如何實現(xiàn)呢？

現(xiàn)在前端代碼都用webpack之類的構建工具打包，那么結合webpack該怎么做，怎么才能做到持久化緩存？

webpack持久化緩存

一、webpack給文件名添加hash值是很簡單的，但hash/chunkhash/contenthash要用哪個呢？

官方定義

hash: unique hash generated for every build

chunkhash: hashes based on each chunks' content

contenthash: hashes generated for extracted content

根據(jù)分析，contenthash才是我們需要的，內容有更新，hash值才會更新。

二、webpack會打包業(yè)務代碼、第三方庫及運行時代碼，為保證緩存互不干擾，應該將它們提取出來。

第三方庫提取方式是設置optimization的splitChunks的cacheGroups。splitChunks能提取模塊，cacheGroups能緩存模塊，并且cacheGroups的配置會覆蓋splitChunks相同配置，既能提取又能緩存，故只需設置cacheGroups。

運行時代碼的提取方式為配置runtimeChunk，默認為false，表示運行時代碼嵌入到不同的chunk文件中；現(xiàn)在將運行時代碼提取出來，并命名為manifest。

module.exports = {
  entry: {
    index: "./src/index.js",
    bar: "./src/bar.js"
  },
  output: {
    filename: "[name].[contenthash].js"
  },
  optimization: {
    splitChunks: {
      cacheGroups: {
        vendor: {
          test:/[\\/]node_modules[\\/]/,
          name: "vendors",
          chunks: "all"
        }
      }
    },
    runtimeChunk: {
      name: "manifest"
    }
  }
};

三、 moduleName 和 chunkName 對文件的影響

module：就是js模塊

chunk：webpack編譯過程中由多個module組成的文件

bundle：bundle是chunk文件的最終狀態(tài)，是webpack編譯后的結果

一個文件被分離為3個文件，文件間怎么相互依賴的，會影響彼此打包，解決方法是將moduleId和chunkId改成按照文件路徑生成。

optimization: {
  moduleIds: 'hashed',
  namedModules: true,
  namedChunks: true
}

這樣子moduleId在編譯后的文件是文件目錄的hash值，更加安全。這也是namedChunks在production默認為false的原因，不想依賴的文件路徑在編譯后的文件直接展示，但是為了持久性緩存，這里也只能打開。

四、CSS文件緩存

當css代碼提取成單獨文件，當我們改變css時，怎么保證不影響引用它的js文件呢？配置如下：

plugins: [
  new MiniCssExtractPlugin({
    filename: "[contenthash].css"
  })
]

webpack持久化緩存目標是當且僅當該文件內容變動才改變該文件名字的hash值

const MiniCssExtractPlugin = require("mini-css-extract-plugin");
module.exports = { 
  output: { 
    filename: [name].[contenthash].js, // 讓hash值只在內容變動時更新 
    chunkFilename: [name].[contenthash].js // 動態(tài)引入的模塊命名，同上 
  }, 
  module: { 
    rules: [ { 
      test: /\.css$/, 
      use: [ 
        "loader: MiniCssExtractPlugin.loader", // 提取出來css "css-loader" 
      ] 
    } ] 
  }, 
  optimization: { 
    moduleIds: "hashed", // 混淆文件路徑名 
    runtimeChunk: { name: 'manifest' }, // 提取runtime代碼命名為manifest 
    namedModules: true, // 讓模塊id根據(jù)路徑設置，避免每增加新模塊，所有id都改變，造成緩存失效的情況 
    namedChunks: true, // 避免增加entrypoint，其他文件都緩存失效 
    cacheGroups: { 
      vendor: { // 提取第三方庫文件 
        test: /[\\/]node_modules[\\/]/, 
        name: 'vendors', chunks: 'all', 
      }, 
    },
  } 
  plugins: [ 
    new webpack.HashedModuleIdsPlugin(), // 與namedModules: true作用一樣 
    new MiniCssExtractPlugin({ 
      filename: "[contenthash].css", // css文件也是按contenthash命名 
      chunkFilename: "[contenthash].css", // 動態(tài)引入的css命名，同上 
    }) 
  ], 
}

總結

瀏覽器有其緩存機制，想要既能緩存又能在部署時沒有問題，需要給靜態(tài)文件名添加hash值。在webpack中，有些配置能讓我們實現(xiàn)持久化緩存。感興趣的同學可以自行去測試哦！

有任何問題可以在下方留言，想了解更多前端知識歡迎關注公眾號“一郭鮮”，文章也將同步于公眾號，前端學習不迷路

存概述

在很久很久以前人類和洪水作斗爭的過程中，水庫發(fā)揮了至關重要的作用 : 在發(fā)洪水時可以蓄水，緩解洪水對下游的沖擊；在干旱時可以把庫存的水釋放出來以供人們使用。這里的水庫就起著緩存的作用。在如今互聯(lián)網(wǎng)的世界里隨著互聯(lián)網(wǎng)的普及，內容信息越來越復雜，用戶數(shù)和訪問量越來越大，我們的應用需要支撐更多的并發(fā)量，同時我們的應用服務器和數(shù)據(jù)庫服務器所做的計算也越來越多。

但是往往我們的應用服務器資源是有限的，且服務器技術變革是緩慢的，數(shù)據(jù)庫每秒能接受的請求次數(shù)也是有限的，那么如何能夠有效利用有限的資源來提供盡可能大的吞吐量呢？一個有效的辦法就是引入緩存，打破標準流程，每個環(huán)節(jié)中請求可以從緩存中直接獲取目標數(shù)據(jù)并返回，從而減少計算量，有效提升響應速度，讓有限的資源服務更多的用戶。

緩存的定義

緩存就是數(shù)據(jù)交換的緩沖區(qū)（稱作Cache），這個概念最初是來自于內存和 CPU。當某一硬件要讀取數(shù)據(jù)時，會首先從緩存中查找需要的數(shù)據(jù)，如果找到了則直接使用執(zhí)行，緩存找不到的話則從內存中找。由于緩存的運行速度比內存快得多，故緩存的作用就是幫助硬件更快地運行。

緩存的分類

當用戶從鍵入一個地址到頁面的展示過程中通常包含了很多種緩存。有前端緩存、本地緩存(協(xié)商緩存,強緩存等)到我們的網(wǎng)關緩存(CDN 緩存)、最后到我們服務端緩存。服務端緩存又區(qū)分為進程緩存（本地緩存），還有比較火的分布式緩存，最后到了數(shù)據(jù)庫層面的緩存。如下圖所示:

緩存是一把雙刃劍

在我們通常的軟件設計中，有一些熱點數(shù)據(jù)需要展示到頁面，我們通常當這些數(shù)據(jù)緩存到內存或者其他讀寫速度優(yōu)異的框架中。減少與數(shù)據(jù)庫進行 I/O 操作。提升數(shù)據(jù)的響應速度。這一切看起來就是這么完美。

實際上，在緩存系統(tǒng)的設計架構中，還有很多坑。如果設計不當會導致很多嚴重的后果。設計不當，輕則請求變慢、性能降低，重則會數(shù)據(jù)不一致、系統(tǒng)可用性降低，甚至會導致緩存雪崩，整個系統(tǒng)無法對外提供服務。

接下來我們著重講述一下在緩存設計過程中幾大經(jīng)典的問題。

緩存失效

先解釋一下什么叫做緩存失效

我們在存放緩存的時候，可以指定緩存 Key 的失效時間，當失效時間到了，此緩存就會失效，由于在緩存中找不到該數(shù)據(jù)，所以這個時候如果用戶有請求該數(shù)據(jù)就繞過緩存直接到數(shù)據(jù)庫中請求數(shù)據(jù)。

看到這里小伙伴們肯定有很多問號？

這不是很正常的現(xiàn)象嘛？為什么要把這個問題拿出來說呢？莫急看下圖圖示

這里我們通過兩個場景來說明一下

• 場景一：這種情況下一般不會對數(shù)據(jù)庫造成比較嚴重的影響，因為失效的 key 的數(shù)量比較少，即使同時請求到數(shù)據(jù)庫層面也是可以接受的。
• 場景二：在這種場景中，當緩存里面的大量 Key 同時失效，這個時候如果有請求過來，會穿過失效的 Key全部落到數(shù)據(jù)庫層面。導致數(shù)據(jù)庫的負荷瞬間添加。可能會出現(xiàn)數(shù)據(jù)庫宕機等特大事故。

解決方案

看到這里很多聰明的小伙伴其實已經(jīng)想到了。場景 2 的事故主要因為很多 key 一起失效的原因，跟我們日常寫緩存的過期時間息息相關。如果我們在日常的開發(fā)過程中需要將一批 Key 設置到緩存中并制定失效時間。這個時候就要注意場景 2 發(fā)生的情況。我們可以在失效時間 + 隨機時間。避免大量 Key 失效沖擊我們的數(shù)據(jù)庫。

緩存擊穿

通常情況下，我們去查詢數(shù)據(jù)都是存在的。那么如果請求去查詢一條壓根兒數(shù)據(jù)庫中根本就不存在的數(shù)據(jù)，也就是緩存和數(shù)據(jù)庫都查詢不到的這條數(shù)據(jù)會怎么樣呢？這樣會導致每次訪問都會直接打到數(shù)據(jù)庫上面去。這種查詢不存在數(shù)據(jù)的現(xiàn)象我們稱為緩存穿透。

下面是緩存失效的場景

很多伙伴看到這里肯定又會覺得這是一件很正常的事情。試想一下，如果有黑客會對你的系統(tǒng)進行攻擊，拿一個不存在的 key 不停的去查詢數(shù)據(jù)，會產(chǎn)生大量的請求到數(shù)據(jù)庫去查詢。可能會導致你的數(shù)據(jù)庫由于壓力過大而宕掉。

解決方案一

• 首先我們能想到的就是在網(wǎng)關參數(shù)進行過濾。校驗請求的 key 是否是我們系統(tǒng) key 的格式等

當然這網(wǎng)關層所能做到的只是一些簡單過濾。每個后端的設計人員應該對服務的可用性和健壯性負責。接下來我們看看服務端應該如何處理

• 服務端可以將不存在的 key 暫時保存到我們的緩存中，再次接收到同樣的請求后如果直接命中緩存并且值為空那么就會直接返回，不會穿透到數(shù)據(jù)庫層面，這樣就避免了緩存擊穿。

但是黑客/惡意攻擊者是不會這么輕易被打發(fā)的。每次請求都會傳不同的 key 來攻擊我們的服務。這個時候這個方案起不到作用了。

解決方案二

構建一個 BloomFilter(布隆過濾器) 緩存過濾器，記錄全量數(shù)據(jù)。這樣訪問數(shù)據(jù)時，可以直接通過 BloomFilter 判斷這個 key 是否存在，如果不存在直接返回即可，根本無需查緩存和 DB。這樣在緩存之前加了一層校驗。如果key 值不存在，就不會請求到我們的緩存更加不會到我們的數(shù)據(jù)庫中。

布隆過濾器可以理解為一個不怎么精確的 set結構，當你使用它的 contains 方法判斷某個對象是否存在時，它可能會誤判。但是布隆過濾器也不是特別不精確，只要參數(shù)設置的合理，它的精確度可以控制的相對足夠精確，只會有小小的誤判概率。當布隆過濾器說某個值存在時，這個值可能不存在；當它說不存在時，那就肯定不存在。即使誤判不存在走到緩存和后端服務也是可以接受的。

緩存雪崩

緩存雪崩是指緩存的部分節(jié)點不可用導致整個緩存體系甚至整個服務系統(tǒng)不可用。

那么你可能會有疑問，緩存雪崩和緩存擊穿有什么關系呢？

從概念上來看，緩存擊穿是因為查詢不存在的 key 穿透緩存直接訪問我們的數(shù)據(jù)庫。而緩存雪崩是因為我們的緩存節(jié)點不可用，請求未經(jīng)過緩存就直到了我們的數(shù)據(jù)庫層面。然而兩者都會影響我們的服務穩(wěn)定性。

緩存節(jié)點的不可用會導致緩存雪崩，那么我們緩存組件集群部署是不是就解決了這個問題呢？

集群部署有兩種情況：

• 一種就是簡單的主從例如 redis 的哨兵之殤
• 采取一致性 hash 算法集群部署例如 redis 的分片集群

第一種情況：發(fā)送雪崩的時候一般是多個節(jié)點同時不可用，例如我們的節(jié)點服務器內容不足，雖然分主從節(jié)點都是存儲的數(shù)據(jù)都是一樣的。如果緩存中的數(shù)據(jù)過大導致節(jié)點不可用。那大部分節(jié)點也會存在這個問題。請求會大面積的落到數(shù)據(jù)庫層面導致后端系統(tǒng)崩潰。

第二種情況: 首先看一下下圖雖然數(shù)據(jù)根據(jù)會根據(jù)取模算法分配到不同的節(jié)點中，假設節(jié)點 A 不可用，數(shù)據(jù) A 會按照逆時針找到節(jié)點 B，會因為本來應該存放到節(jié)點 A 的數(shù)據(jù)存放到節(jié)點 B，以此類推會導致整個緩存節(jié)點不可用。請求也會大面積落到我們后端的數(shù)據(jù)庫層面導致系統(tǒng)崩潰。

解決方案

• 對緩存體系進行實時監(jiān)控，當請求訪問的慢速比超過閥值時，及時報警，通過機器替換、服務替換進行及時恢復。
• 對緩存增加多個副本，緩存異常或請求 miss 后，再讀取其他緩存副本。
• ehcache 本地緩存 + Hystrix 限流&降級，避免 MySQL被打死
• 業(yè)務 DB 的訪問增加讀寫開關，當發(fā)現(xiàn) DB 請求變慢、阻塞，慢請求超過閥值時，就會關閉讀開關，部分或所有讀 DB 的請求進行 failfast 立即返回，待 DB 恢復后再打開讀開關。

數(shù)據(jù)不一致

數(shù)據(jù)不一致的概念很簡單：就是緩存中的數(shù)據(jù)和數(shù)據(jù)庫中的數(shù)據(jù)不一致。

那為什么會不一致呢？我們的數(shù)據(jù)被緩存之后，一旦數(shù)據(jù)被修改（修改時也是刪除緩存中的數(shù)據(jù)）或刪除，我們就需要同時操作緩存和數(shù)據(jù)庫。這時就會存在一個數(shù)據(jù)不一致的問題。

如上圖所示當我們先刪除數(shù)據(jù)庫再去操作緩存，緩存中未刪除數(shù)據(jù)庫其實已經(jīng)不存在該數(shù)據(jù)了。這個時候就會出現(xiàn)緩存不一致的情況。

聰明的小伙伴肯定想到了我們還是需要先做緩存刪除操作，再去完成數(shù)據(jù)庫操作。則會去數(shù)據(jù)庫中查詢，如果緩存中沒有該數(shù)據(jù)，則會去數(shù)據(jù)庫中查詢，之后再放入到緩存中。這樣就完美了嘛？答案肯定不會這么簡單。請看下圖:

解決方案

這里其實沒有什么很完美的解決方法。可以將變更的 key 添加到安全隊列中。當另一個查詢請求 B 進來時，如果發(fā)現(xiàn)緩存中沒有該值，則會先去隊列中查看該數(shù)據(jù)是否正在被更新或刪除，如果隊列中有該數(shù)據(jù)，則阻塞等待，直到 A 操作數(shù)據(jù)庫成功之后，喚醒該阻塞線程，再去數(shù)據(jù)庫中查詢該數(shù)據(jù)。這里其實也是有很多缺陷的。線程需要阻塞等待。

最好的解決方案就是如果數(shù)據(jù)更新比較頻繁且對數(shù)據(jù)有一定的一致性要求，我通常不建議使用緩存。看到這里是不是發(fā)出了一句切！！！！

總結

緩存雖然能大幅度的提高服務器的性能以及用戶的體驗感。但是隨著而來的就是各種由于緩存導致的一系列問題。所以當我們使用緩存的過程中需要注意以上的經(jīng)典問題。

<script type="text/javascript" src="lib/common.js?v=20190719"></script>
<link rel="stylesheet" type="text/css" href="assets/css/ie/ie8.css?v=20190719" />

document.write('<script src=\".lib/common.js?r=' + Math.random() + "\"" + '><\/script>');

entry: {
 main: './src/common.js',
 slove: './src/ie8.js'
},
output: {
 filename: '[name].[hash].js',
 path: path.resolve(__dirname, 'dist')
}