資訊專欄INFORMATION COLUMN
摘要：但是這篇文章除去科普基本概念外，更重要的就是介紹中間件思想，并自己來實現一個服務端緩存中間件。
Express 作為 Node.js 的框架，如今發展可謂如日中天。我很喜歡其靈活、易擴展的設計理念。尤其是該框架的中間件架構設計：使得在應用中加入新特性更加標準化、成本最小化。這篇文章，我會嘗試編寫一個非常簡單、小巧的中間件，完成服務端緩存功能，進而優化性能。
關于中間件說到中間件，Express 官網對它的闡述是這樣的：
“Express 是一個自身功能極簡，完全是路由和中間件構成一個web開發框架：從本質上來說，一個 Express 應用就是在調用各種中間件?！?/p>
也許你使用過各種各樣的中間件進行開發，但是可能并不理解中間件原理，也沒有深入過 Express 源碼，探究其實現。這里并不打算長篇大論幫您分析，但是使用層面上大致可以參考下圖：
建議有興趣、想深入的讀者自己分析，有任何問題歡迎與我討論。即便您不打算深入，也不會影響對下文中間件編寫的理解。
關于服務端緩存緩存已經被廣泛應用，來提高頁面性能。一說到緩存，可能讀者腦海里馬上冒出來：“客戶端緩存，CDN 緩存，服務器端緩存......”。另一維度上，也會想到：“200（from cache），expire，eTag......”等概念。
當然作為前端開發者，我們一定要明白這些緩存概念，這些緩存理念是相對于某個具體用戶訪問來說的，性能優化體現在單個用戶上。比如說，我第一次打開頁面 A，耗時超長，下一次打開頁面由于緩存的作用，時間縮短了。
但是在服務器端，還存在另外一個維度，思考一下這樣的場景：
我們有一個靜態頁面 B，這個頁面服務端需要從數據庫獲取部分數據 b1，根據 b1 又要計算得到部分數據 b2，還得做各種高復雜度操作，最終才能“東拼西湊”出需要返回的完整頁面 B，整個過程耗時2s。
那么面臨的災難就是，user1 打開頁面耗時2s，user2同樣打開頁面耗時2s......而這些頁面都是靜態頁面 B，內容是完全一樣的。為了解決這個災難，這時候我們也需要緩存，這種緩存就叫先做服務端緩存（server-side cache）。
總結一下，服務端緩存的目的其實就是對于同一個頁面請求，而返回（緩存的）同樣的頁面內容。這個過程完全獨立于不同的用戶。
上面的話有些拗口，可以參考英文表達更清晰：
The goal of server side cache is responding to the same content for the same request independently of the client’s request.
因此，下面展示的 demo 在第一次請求到達時，服務端耗費5秒來返回 HTML；而接下來再次請求該頁面，將會命中緩存，不過是哪個用戶訪問，只需要幾毫秒便可得到完整頁面。
Show me the code & Demo其實上文提到的緩存概念非常簡單，稍微有些后端經驗的同學都能很好理解。但是這篇文章除去科普基本概念外，更重要的就是介紹 Express 中間件思想，并自己來實現一個服務端緩存中間件。
讓我們開工吧！
最終 Demo 代碼，歡迎訪問它的Github地址。
我將會使用 npm 上 memory-cache 這個包，以方便進行緩存的讀寫。最終的中間件代碼很簡單：
"use strict"
var mcache = require("memory-cache");
var cache = (duration) => {
return (req, res, next) => {
let key = "__express__" + req.originalUrl || req.url
let cachedBody = mcache.get(key)
if (cachedBody) {
res.send(cachedBody)
return
} else {
res.sendResponse = res.send
res.send = (body) => {
mcache.put(key, body, duration * 1000);
res.sendResponse(body)
}
next()
}
}
}
為了簡單，我使用了請求 URL 作為 cache 的 key：
當它（cache key）及其對應的 value 值存在時，便直接返回其 value 值；
當它（cache key）及其對應的 value 值不存在時，我們將對 Express send 方法做一層攔截：在最終返回前，存入這對 key-value。
緩存的有效時間是10秒。
最終在判斷之外，我們的中間件把控制權交給下一個中間件。
最終使用和測試如下代碼：
app.get("/", cache(10), (req, res) => {
setTimeout(() => {
res.render("index", { title: "Hey", message: "Hello there", date: new Date()})
}, 5000) //setTimeout was used to simulate a slow processing request
})
我使用了 setTimeout 來模擬一個超長（5s）的操作。
打開瀏覽器控制面板，發現在10秒緩存到期以內：
至于為什么 cache 中間件要那樣子寫、next() 為什么是中間件把控制權傳遞，我并不打算展開去講。有興趣的讀者可以看一下 Express 源碼。
還有幾個小問題仔細看我們的頁面，再去體會一下實現代碼。也許細心的讀者能發現一個問題：剛才的實現我們緩存了整個頁面，并將 date: new Date() 傳入了 jade 模版 index.jade 里。那么，在命中緩存的條件下，10秒內，頁面無法動態刷新來同步，直到10秒緩存到期。
同時，我們什么時候可以使用上述中間件，進行服務端緩存呢？當然是靜態內容才可以使用。同時，PUT, DELETE 和 POST 操作都不應該進行類似的緩存處理。
同樣，我們使用了 npm 模塊：memory-cache，它存在優缺點如下：
讀寫迅速而簡單，不需要其他依賴；
當服務器或者這個進程掛掉的時候，緩存中的內容將會全部丟失。
memcache 是將緩存內容存放在了自己進程的內存中，所以這部分內容是無法在多個 Node.js 進程之間共享的。
如果這些弊端 really matter，在實際開發中我們可以選擇分布式的 cache 服務，比如 Redis。同樣你可以在 npm 上找到：express-redis-cache 模塊使用。
總結在真實的開發場景中，服務端緩存已經成為 common sense，但是在 Node.js 的世界里，體會其中間件思想，自己手動編寫服務，同樣樂趣無窮。
與實踐相結合，我認為真正緩存整個頁面（如同 demo 那樣）并不是一個推薦的做法（當時實際場景實際分析），同樣使用請求 url 作為緩存的 key 也有待考慮。比如，頁面中的一些靜態內容可能會在其他頁面中重復使用到，復用就成了問題。
真實場景下，一切設計和邏輯都要為自己業務情況所負責。脫離需求談實現，都是耍流氓。這個 demo 簡易輕巧，有需要的讀者可以訪問它的Github地址，歡迎玩出各種花樣。
Happy Coding!
PS:
作者Github倉庫 和 知乎問答鏈接
歡迎各種形式交流。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/88400.html
摘要：前端日報精選機制詳解與中實踐應用基礎與實踐如何用獲取虛擬鍵盤高度適用所有平臺和入門教程阮一峰的網絡日志編程技能提升指南中文到底什么是又是什么眾成翻譯調用模塊騰訊前端團隊社區小書從一個簡單的例子講起小書教程小書優化操作小書教 2017-09-07 前端日報 精選 JavaScript Event Loop 機制詳解與 Vue.js 中實踐應用 Redux 基礎與實踐如何用 js 獲取虛擬...
摘要：這個由提供的工具。在轉換步驟是異步時，你可以這樣告訴本次轉換是異步的，會在中回調結果通過返回異步執行后的結果參考編寫一個 本文示例源代碼請戳github博客，建議大家動手敲敲代碼。 本文不會介紹loader的一些使用方法，不熟悉的同學請自行查看Webpack loader 1、背景 首先我們來看一下為什么需要loader，以及他能干什么?webpack 只能理解 JavaScript...
摘要：前言一直很喜歡看科技新聞，多年來一直混跡于，以前西貝的評論區是匿名的，所以評論區非常活躍，各種噴子和段子，不過也確實很歡樂，可以說那是西貝人氣最旺的時候。 前言 一直很喜歡看科技新聞，多年來一直混跡于cnBeta，以前西貝的評論區是匿名的，所以評論區非?；钴S，各種噴子和段子，不過也確實很歡樂，可以說那是西貝人氣最旺的時候。然而自從去年網信辦出臺了《互聯網跟帖評論服務管理規定》，要求只有...
摘要：前言一直很喜歡看科技新聞，多年來一直混跡于，以前西貝的評論區是匿名的，所以評論區非?；钴S，各種噴子和段子，不過也確實很歡樂，可以說那是西貝人氣最旺的時候。 前言 一直很喜歡看科技新聞，多年來一直混跡于cnBeta，以前西貝的評論區是匿名的，所以評論區非常活躍，各種噴子和段子，不過也確實很歡樂，可以說那是西貝人氣最旺的時候。然而自從去年網信辦出臺了《互聯網跟帖評論服務管理規定》，要求只有...
閱讀 2464·2021-09-29 09:34
閱讀 3300·2021-09-23 11:21
閱讀 2494·2021-09-06 15:00
閱讀 1123·2019-08-30 15:44
閱讀 2023·2019-08-29 17:23
閱讀 2996·2019-08-29 16:44
閱讀 3051·2019-08-29 13:13
閱讀 1932·2019-08-28 18:12
