快捷導(dǎo)航

nuxt.js 緩存實踐

更新時間：2018年06月25日 14:16:21 作者：nw2018

這篇文章主要介紹了nuxt.js 緩存實踐，nuxt 的緩存可以分為組件級別緩存 , API級別緩存以及頁面級別緩存，本文就詳細的介紹了這三種緩存，感興趣的小伙伴們可以參考一下

nuxt 是基于 vue 的 ssr 解決方案，可以是使用vue語法完成前后端的同構(gòu)。

然而在與傳統(tǒng)純字符串拼接的 ssr 方案相比，性能就沒那么好了， nuxt 需要在服務(wù)端生成虛擬 dom ，然后再序列化出HTML字符串，我們常說 nodejs 的高性能指的是異步IO操作頻繁的場景而非CPU操作密集的場景，畢竟 nodejs 是運行在單線程下的，在涉及到高并發(fā)的場景下，性能就會有所下降，可以考慮采用合理的緩存策略

nuxt 的緩存可以分為組件級別緩存 , API級別緩存以及頁面級別緩存

組件級別的緩存

配置項 nuxt.config.js 的配置大概長這樣子:

const LRU = require('lru-cache')
module.exports = {
 render: {
  bundleRenderer: {
   cache: LRU({
    max: 1000,           // 最大的緩存?zhèn)€數(shù)
    maxAge: 1000 * 60 * 15    // 緩存15分鐘
   })
  }
 }
}

并不是說配了該項就實現(xiàn)了組件級別的緩存，還需要在需做緩存的 vue 組件上增加 name 以及 serverCacheKey 字段，以確定緩存的唯一鍵值，比如：

export default {
 name: 'AppHeader',
 props: ['type'],
 serverCacheKey: props => props.type
}

上述組件會根據(jù)父組件傳下來的 type 值去做緩存，鍵值是： AppHeader::${props.type} ，由此，新的請求到來時，只要父組件傳下來的 type 屬性之前處理過，就可以復(fù)用之前的渲染緩存結(jié)果，以增進性能

從該例子可以看出，如果該組件除了依賴父組件的 type 屬性，還依賴于別的屬性， serverCacheKey 這里也要做出相應(yīng)的改變，因此，如果組件依賴于很多的全局狀態(tài)，或者，依賴的狀態(tài)取值非常多，意味需要緩存會被頻繁被設(shè)置而導(dǎo)致溢出，其實就沒有多大意義了，在 lru-cache 的配置中，設(shè)置的最大緩存?zhèn)€數(shù)是1000，超出部分就會被清掉

其次，不應(yīng)該緩存可能對渲染上下文產(chǎn)生副作用的子組件，比如，組件的 created 與 beforeCreated 的鉤子在服務(wù)端也會走，組件被緩存后就不會執(zhí)行了，這些可能影響到渲染上下文的地方也要小心，更多內(nèi)容請參考：組件級別緩存

一般來說，比較適合的場景是 v-for 大量數(shù)據(jù)的渲染，因為循環(huán)操作比較耗cpu

API級別的緩存

在服務(wù)端渲染的場景中，往往會將請求放在服務(wù)端去做，渲染完頁面再返回給瀏覽器，而有些接口是可以去做緩存的，比如，不依賴登錄態(tài)且不依賴過多參數(shù)的接口或者是單純獲取配置數(shù)據(jù)的接口等，接口的處理也是需要時間的，對接口的緩存可以加快每個請求的處理速度，更快地釋放掉請求，從而增進性能

api的請求使用 axios ， axios 即可以在服務(wù)端使用也可是在瀏覽器使用，代碼大概長這樣子

import axios from 'axios'
import md5 from 'md5'
import LRU from 'lru-cache'

// 給api加3秒緩存
const CACHED = LRU({
 max: 1000,
 maxAge: 1000 * 3
})

function request (config) {
 let key
 // 服務(wù)端才加緩存，瀏覽器端就不管了
 if (config.cache && !process.browser) {
  const { params = {}, data = {} } = config
  key = md5(config.url + JSON.stringify(params) + JSON.stringify(data))
  if (CACHED.has(key)) {
   // 緩存命中
   return Promise.resolve(CACHED.get(key))
  }
 }
 return axios(config)
  .then(rsp => {
   if (config.cache && !process.browser) {
    // 返回結(jié)果前先設(shè)置緩存
    CACHED.set(key, rsp.data)
   }
   return rsp.data
  })
}

使用上跟平時使用 axios 還是一樣的，就多加了個 cache 的屬性標(biāo)識是否需要在服務(wù)端做緩存

const api = {
 getGames: params => request({
  url: '/gameInfo/gatGames',
  params,
  cache: true
 })
}

頁面級別的緩存

在不依賴于登錄態(tài)以及過多參數(shù)的情況下，如果并發(fā)量很大，可以考慮使用頁面級別的緩存，在 nuxt.config.js 增加 serverMiddleware 屬性

const nuxtPageCache = require('nuxt-page-cache')

module.exports = {
 serverMiddleware: [
  nuxtPageCache.cacheSeconds(1, req => {
   if (req.query && req.query.pageType) {
    return req.query.pageType
   }
   return false
  })
 ]
}

上面的例子根據(jù)鏈接后面的參數(shù) pageType 去做緩存，如果鏈接后面有 pageType 參數(shù)，就做緩存，緩存時間為1秒，也就是說在1秒內(nèi)相同的 pageType 請求，服務(wù)端只會執(zhí)行一次完整的渲染

nuxt-page-cache 參考了route-cache ，寫得比較簡陋，你也可以重新封裝下，nuxt最終返回數(shù)據(jù)是使用 res.end(html, 'utf-8') ，頁面級別的緩存大概的思想如下：

const LRU = require('lru-cache')

let cacheStore = new LRU({
 max: 100,     // 設(shè)置最大的緩存?zhèn)€數(shù)
 maxAge: 200
})

module.exports.cacheSeconds = function (secondsTTL, cacheKey) {
 // 設(shè)置緩存的時間
 const ttl = secondsTTL * 1000
 return function (req, res, next) {
  // 獲取緩存的key值
  let key = req.originalUrl
  if (typeof cacheKey === 'function') {
   key = cacheKey(req, res)
   if (!key) { return next() }
  } else if (typeof cacheKey === 'string') {
   key = cacheKey
  }

  // 如果緩存命中，直接返回
  const value = cacheStore.get(key)
  if (value) {
   return res.end(value, 'utf-8')
  }

  // 緩存原先的end方案
  res.original_end = res.end

  // 重寫res.end方案，由此nuxt調(diào)用res.end實際上是調(diào)用該方法，
  res.end = function () {
   if (res.statusCode === 200) {
    // 設(shè)置緩存
    cacheStore.set(key, data, ttl)
   }
   // 最終返回結(jié)果
   res.original_end(data, 'utf-8')
  }
 }
}

如果緩存命中，直接將原先的計算結(jié)果返回，大大提供了性能

總結(jié)

在高并發(fā)的情況下可以考慮使用緩存，而緩存策略的使用需要視場景而定，這里不再贅述，還可以考慮使用pm2開啟集群模式去管理我們的進程，從而滿足更高的并發(fā)。

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

您可能感興趣的文章: