业务场景

前一段时间刚做完一个我的项目，先说一下业务场景，有别于其余的前端我的项目，这次的我的项目是间接调用第三方服务的接口，而咱们的服务端只做鉴权和透传，第三方为了灵便，把接口拆的很零散，所以这个我的项目就像扔给你一堆乐高颗粒让你组装成一个机器人。所以能够大略剖析一下这个我的项目在申请接口时的一些特点，而后针对性的做一些优化：

  1. 申请接口多，可能你的一个n个条目标列表原本一个接口搞定当初须要n*10个接口能力拿到残缺的数据，有些功能模块可能须要申请成千上万次接口；
  2. 根本都是get申请，只读不写；
  3. 接口调用反复率高，因为接口很细碎，所以可能有些罕用的接口须要反复调用；
  4. 接口返回的数据实时性要求不高，第三方的数据不是实时更新的，可能一天或者一周才更新一次，然而第三方要求不能以任何的形式落库。

所以综上剖析，前端缓存成了一个可行性较高的优化计划。

解决方案

前端的HTTP申请应用的是Axios，因而能够利用Axios的拦截器进行缓存的治理。梳理一下逻辑：

  1. 创立缓存对象；

  2. 申请发动之前判断该申请是否命中缓存：

    1. 是，间接返回缓存内容；
    2. 否，发动申请，申请胜利后将申请后果存入缓存中。

如题目所说，这里的缓存策略咱们用的是LRU（Least Recently Used）策略，因为缓存不能无限大，过大的缓存可能会导致浏览器页面性能降落，甚至内存透露。LRU会在缓存达到最大承载量后删除最近起码应用的缓存内容，因而不必放心缓存有限增大。那么如何实现LRU缓存策略呢？Github上有现成的轮子，然而为了更深刻的学习嘛，咱们本人来手动实现一个。

实现LRU

LRU次要有两个性能，存、取。梳理一下逻辑：

  1. 存入：

    1. 如果缓存已满，删除最近起码应用的缓存内容，把以后的缓存存进去，放到最罕用的地位；
    2. 否则间接将缓存存入最罕用的地位。

  2. 读取：

    1. 如果存在这个缓存，返回缓存内容，同时把该缓存放到最罕用的地位；
    2. 如果没有，返回-1。

这里咱们能够看到，缓存是有优先级的，咱们用什么来表明优先级呢？如果用数组存储能够将不罕用的放到数组的头部，将罕用的放到尾部。然而鉴于数据的插入效率不高，这里咱们应用Map对象来作为容器存储缓存。

代码如下：

class LRUCache {    constructor(capacity) {        if (typeof capacity !== 'number' || capacity < 0) {            throw new TypeError('capacity必须是一个非正数');        }        this.capacity = capacity;        this.cache = new Map();    }    get(key) {        if (!this.cache.has(key)) {            return -1;        }        let tmp = this.cache.get(key);        // 将以后的缓存挪动到最罕用的地位        this.cache.delete(key);        this.cache.set(key, tmp);        return tmp;    }    set(key, value) {        if (this.cache.has(key)) {            // 如果缓存存在更新缓存地位            this.cache.delete(key);        } else if (this.cache.size >= this.capacity) {            // 如果缓存容量已满，删除最近起码应用的缓存            this.cache.delete(this.cache.keys().next.val);        }        this.cache.set(key, value);    }}

联合Axios实现申请缓存

理一下大略的逻辑：每次申请依据申请的办法、url、参数生成一串hash，缓存内容为hash->response，后续申请如果申请办法、url、参数统一，即认为命中缓存。

代码如下：

import axios from 'axios';import md5 from 'md5';import LRUCache from './LRU.js';const cache = new LRUCache(100);const _axios = axios.create();// 将申请参数排序，避免雷同参数生成的hash不同function sortObject(obj = {}) {    let result = {};    Object.keys(obj)        .sort()        .forEach((key) => {            result[key] = obj[key];        });}// 依据request method,url,data/params生成cache的标识function genHashByConfig(config) {    const target = {        method: config.method,        url: config.url,        params: config.method === 'get' ? sortObject(config.params) : null,        data: config.method === 'post' ? sortObject(config.data) : null,    };    return md5(JSON.stringify(target));}_axios.interceptors.response.use(    function(response) {        // 设置缓存        const hashKey = genHashByConfig(response.config);        cache.set(hashKey, response.data);        return response.data;    },    function(error) {        return Promise.reject(error);    });// 将axios申请封装，如果命中缓存就不须要发动http申请，间接返回缓存内容export default function request({    method,    url,    params = null,    data = null,    ...res}) {    const hashKey = genHashByConfig({ method, url, params, data });    const result = cache.get(hashKey);    if (~result) {        console.log('cache hit');        return Promise.resolve(result);    }    return _axios({ method, url, params, data, ...res });}

申请的封装：

import request from './axios.js';export function getApi(params) {    return request({        method: 'get',        url: '/list',        params,    });}export function postApi(data) {    return request({        method: 'post',        url: '/list',        data,    });}

这里须要留神的一点是，我将申请办法，url，参数进行了hash操作，为了避免参数的程序扭转而导致hash后果不统一，我在hash操作之前，给参数做了排序解决，理论开发中，参数的类型也不肯定就是object，能够依据本人的需要进行革新。

如上革新后，第一次申请后，雷同的申请再次触发就不会发送http申请了，而是间接从缓存中获取，真是多快好省~

参考：JS 实现一个 LRU 算法