雖然 Vue 的服務(wù)器端渲染 (SSR) 相當(dāng)快速，但是由于需要為每次請(qǐng)求為了避免交叉請(qǐng)求狀態(tài)污染，都創(chuàng)建一個(gè)新的根Vue實(shí)例，創(chuàng)建組件實(shí)例和虛擬 DOM 節(jié)點(diǎn)的開(kāi)銷(xiāo)，無(wú)法與純基于字符串拼接的模板的性能相當(dāng)。在 SSR 性能至關(guān)重要的情況下，明智地利用緩存策略，可以極大改善響應(yīng)時(shí)間并減少服務(wù)器負(fù)載。同時(shí)還可以大大減少后端接口服務(wù)器的負(fù)載。

在 vue SSR指南 中，緩存有兩種，分為頁(yè)面級(jí)緩存和組件級(jí)緩存。本次講的是頁(yè)面緩存，如果內(nèi)容不是用戶(hù)特定的并且在相對(duì)較短時(shí)間內(nèi)，頁(yè)面內(nèi)容不需要更新。我們就可以使用頁(yè)面緩存。對(duì)于頁(yè)面級(jí)緩存我們可以通過(guò)這段koa服務(wù)器的代碼大概知道緩存的思路：

const microCache = LRU({
 max: 100,
 maxAge: 1000 // 重要提示：條目在 1 秒后過(guò)期。
})

const isCacheable = req => {
 // 實(shí)現(xiàn)邏輯為，檢查請(qǐng)求是否是用戶(hù)特定(user-specific)。
 // 只有非用戶(hù)特定 (non-user-specific) 頁(yè)面才會(huì)緩存
}

server.get('*', (req, res) => {
 const cacheable = isCacheable(req)
 if (cacheable) {
 const hit = microCache.get(req.url)
 if (hit) {
  return res.end(hit)
 }
 }

 renderer.renderToString((err, html) => {
 res.end(html)
 if (cacheable) {
  microCache.set(req.url, html)
 }
 })
})

流程圖如下：

上面的代碼為vue的ssr渲染提供了方案，但是對(duì)于使用nuxt框架的同學(xué)而言，用腳手架初始化完，框架對(duì)于vue服務(wù)端渲染的res.end()函數(shù)做了高度封裝，從下圖nuxt在接收到請(qǐng)求后進(jìn)行渲染的流程可以看出，nuxt主要是通過(guò)nuxtMiddleware調(diào)用renderRoute()來(lái)進(jìn)行渲染的：

那么我們是否可以通過(guò)重寫(xiě)renderRoute()這個(gè)api攔截其內(nèi)部渲染邏輯，在渲染之前加上緩存呢？ nuxt-ssr-cache 插件已經(jīng)這樣做了。我們來(lái)看一下這個(gè)nuxt模塊核心部分的源碼：

const renderer = nuxt.renderer;
const renderRoute = renderer.renderRoute.bind(renderer);
renderer.renderRoute = function(route, context) {
 // hopefully cache reset is finished up to this point.
 tryStoreVersion(cache, currentVersion);

 const cacheKey = (config.cache.key || defaultCacheKeyBuilder)(route, context);
 if (!cacheKey) return renderRoute(route, context);

 function renderSetCache(){
  return renderRoute(route, context)
   .then(function(result) {
    if (!result.error) {
     cache.setAsync(cacheKey, serialize(result));
    }
    return result;
   });
 }

 return cache.getAsync(cacheKey)
  .then(function (cachedResult) {
   if (cachedResult) {
    return deserialize(cachedResult);
   }

   return renderSetCache();
  })
  .catch(renderSetCache);
};

在這段代碼中，先保存了renderer原來(lái)的renderRoute代碼，之后又重寫(xiě)了renderRoute代碼，返回了一個(gè)通過(guò)cache緩存來(lái)獲取緩存內(nèi)容的邏輯。cache返回了一個(gè)promise，如果是resolve的，并且有緩存的內(nèi)容，就直接返回緩存內(nèi)容。如果沒(méi)有緩存內(nèi)容或者reject，就執(zhí)行renderSetCache()。而renderSetCache()中，返回了原來(lái)最初的renderRoute()處理邏輯，同樣如果renderRoute()返回的promise被resolve了，那么就通過(guò)cache的setAsync方法來(lái)進(jìn)行緩存，之后返回渲染結(jié)果。

使用方法大家自行參考git中的readme文檔，這里就不說(shuō)了。

下面我們真正來(lái)仿真一下，看看這個(gè)模塊的功效到底如何。我們通過(guò)ab命令

ab -n 4000 -c 50 -s 120 -r http://localhost:3000/

來(lái)進(jìn)行壓測(cè)：

第一種情況，沒(méi)有添加頁(yè)面緩存，大約持續(xù)請(qǐng)求了10秒鐘，執(zhí)行到3600個(gè)請(qǐng)求的時(shí)候，發(fā)生錯(cuò)誤，不再繼續(xù)請(qǐng)求了：

我們來(lái)通過(guò)日志看下是什么錯(cuò)誤：

可以看到FATAL ERROR這一句，JavaScript heap out of memory。堆內(nèi)存已經(jīng)沒(méi)有辦法再進(jìn)行分配，所以進(jìn)程終止了。

我們?cè)诮K止之前通過(guò)進(jìn)程監(jiān)視器可以看到node進(jìn)程已經(jīng)彪到了1.7GB的內(nèi)存。

第二種情況，我們添加了頁(yè)面緩存，通過(guò)server端的日志，我們可以看出，只請(qǐng)求了一次后端的api數(shù)據(jù)接口，說(shuō)明緩存已經(jīng)成功攔截了頁(yè)面請(qǐng)求。請(qǐng)求數(shù)據(jù)如下：

在2秒鐘之內(nèi)，就順利結(jié)束了4000個(gè)請(qǐng)求，內(nèi)存沒(méi)有任何明顯波動(dòng)，優(yōu)化效果顯而易見(jiàn)。

到此這篇關(guān)于Nuxt頁(yè)面級(jí)緩存的實(shí)現(xiàn)的文章就介紹到這了,更多相關(guān)Nuxt 頁(yè)面級(jí)緩存內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論