Express 作為 Node.js 的框架，如今發(fā)展可謂如日中天。我很喜歡其靈活、易擴(kuò)展的設(shè)計理念。尤其是該框架的中間件架構(gòu)設(shè)計：使得在應(yīng)用中加入新特性更加標(biāo)準(zhǔn)化、成本最小化。這篇文章，我會嘗試編寫一個非常簡單、小巧的中間件，完成服務(wù)端緩存功能，進(jìn)而優(yōu)化性能。

關(guān)于中間件

說到中間件，Express 官網(wǎng)對它的闡述是這樣的：

“Express 是一個自身功能極簡，完全是路由和中間件構(gòu)成一個web開發(fā)框架：從本質(zhì)上來說，一個 Express 應(yīng)用就是在調(diào)用各種中間件。”

也許你使用過各種各樣的中間件進(jìn)行開發(fā)，但是可能并不理解中間件原理，也沒有深入過 Express 源碼，探究其實(shí)現(xiàn)。這里并不打算長篇大論幫您分析，但是使用層面上大致可以參考下圖：

建議有興趣、想深入的讀者自己分析，有任何問題歡迎與我討論。即便您不打算深入，也不會影響對下文中間件編寫的理解。

關(guān)于服務(wù)端緩存

緩存已經(jīng)被廣泛應(yīng)用，來提高頁面性能。一說到緩存，可能讀者腦海里馬上冒出來：“客戶端緩存，CDN 緩存，服務(wù)器端緩存......”。另一維度上，也會想到：“200(from cache)，expire，eTag......”等概念。

當(dāng)然作為前端開發(fā)者，我們一定要明白這些緩存概念，這些緩存理念是相對于某個具體用戶訪問來說的，性能優(yōu)化體現(xiàn)在單個用戶上。比如說，我第一次打開頁面 A，耗時超長，下一次打開頁面由于緩存的作用，時間縮短了。

但是在服務(wù)器端，還存在另外一個維度，思考一下這樣的場景：

我們有一個靜態(tài)頁面 B，這個頁面服務(wù)端需要從數(shù)據(jù)庫獲取部分?jǐn)?shù)據(jù) b1，根據(jù) b1 又要計算得到部分?jǐn)?shù)據(jù) b2，還得做各種高復(fù)雜度操作，最終才能“東拼西湊”出需要返回的完整頁面 B，整個過程耗時2s。

那么面臨的災(zāi)難就是，user1 打開頁面耗時2s，user2同樣打開頁面耗時2s......而這些頁面都是靜態(tài)頁面 B，內(nèi)容是完全一樣的。為了解決這個災(zāi)難，這時候我們也需要緩存，這種緩存就叫先做服務(wù)端緩存(server-side cache)。

總結(jié)一下，服務(wù)端緩存的目的其實(shí)就是對于同一個頁面請求，而返回(緩存的)同樣的頁面內(nèi)容。這個過程完全獨(dú)立于不同的用戶。

上面的話有些拗口，可以參考英文表達(dá)更清晰：

The goal of server side cache is responding to the same content for the same request independently of the client’s request.

因此，下面展示的 demo 在第一次請求到達(dá)時，服務(wù)端耗費(fèi)5秒來返回 HTML;而接下來再次請求該頁面，將會命中緩存，不過是哪個用戶訪問，只需要幾毫秒便可得到完整頁面。

Show me the code & Demo

其實(shí)上文提到的緩存概念非常簡單，稍微有些后端經(jīng)驗(yàn)的同學(xué)都能很好理解。但是這篇文章除去科普基本概念外，更重要的就是介紹 Express 中間件思想，并自己來實(shí)現(xiàn)一個服務(wù)端緩存中間件。

讓我們開工吧!

最終 Demo 代碼，歡迎訪問它的Github地址。

我將會使用 npm 上 memory-cache 這個包，以方便進(jìn)行緩存的讀寫。最終的中間件代碼很簡單：

'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：

• 當(dāng)它(cache key)及其對應(yīng)的 value 值存在時，便直接返回其 value 值;
• 當(dāng)它(cache key)及其對應(yīng)的 value 值不存在時，我們將對 Express send 方法做一層攔截：在最終返回前，存入這對 key-value。

緩存的有效時間是10秒。

最終在判斷之外，我們的中間件把控制權(quán)交給下一個中間件。

最終使用和測試如下代碼：

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)的操作。

打開瀏覽器控制面板，發(fā)現(xiàn)在10秒緩存到期以內(nèi)：

至于為什么 cache 中間件要那樣子寫、next() 為什么是中間件把控制權(quán)傳遞，我并不打算展開去講。有興趣的讀者可以看一下 Express 源碼。

還有幾個小問題

仔細(xì)看我們的頁面，再去體會一下實(shí)現(xiàn)代碼。也許細(xì)心的讀者能發(fā)現(xiàn)一個問題：剛才的實(shí)現(xiàn)我們緩存了整個頁面，并將 date: new Date() 傳入了 jade 模版 index.jade 里。那么，在命中緩存的條件下，10秒內(nèi)，頁面無法動態(tài)刷新來同步，直到10秒緩存到期。

同時，我們什么時候可以使用上述中間件，進(jìn)行服務(wù)端緩存呢?當(dāng)然是靜態(tài)內(nèi)容才可以使用。同時，PUT, DELETE 和 POST 操作都不應(yīng)該進(jìn)行類似的緩存處理。

同樣，我們使用了 npm 模塊：memory-cache，它存在優(yōu)缺點(diǎn)如下：

• 讀寫迅速而簡單，不需要其他依賴;
• 當(dāng)服務(wù)器或者這個進(jìn)程掛掉的時候，緩存中的內(nèi)容將會全部丟失。
• memcache 是將緩存內(nèi)容存放在了自己進(jìn)程的內(nèi)存中，所以這部分內(nèi)容是無法在多個 Node.js 進(jìn)程之間共享的。

如果這些弊端 really matter，在實(shí)際開發(fā)中我們可以選擇分布式的 cache 服務(wù)，比如 Redis。同樣你可以在 npm 上找到：express-redis-cache 模塊使用。

總結(jié)

在真實(shí)的開發(fā)場景中，服務(wù)端緩存已經(jīng)成為 common sense，但是在 Node.js 的世界里，體會其中間件思想，自己手動編寫服務(wù)，同樣樂趣無窮。

與實(shí)踐相結(jié)合，我認(rèn)為真正緩存整個頁面(如同 demo 那樣)并不是一個推薦的做法(當(dāng)時實(shí)際場景實(shí)際分析)，同樣使用請求 url 作為緩存的 key 也有待考慮。比如，頁面中的一些靜態(tài)內(nèi)容可能會在其他頁面中重復(fù)使用到，復(fù)用就成了問題。

作者：lucas_580e331d326b4

來源：51CTO

總結(jié)

以上是生活随笔為你收集整理的教你编写Node.js中间件，实现服务端缓存的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。