Схема кеширования запросов к интерфейсу API

оптимизация производительности

Производительность является важной темой при разработке веб-приложений. Для одностраничных приложений, упакованных с помощью webpack, мы можем оптимизировать производительность многими способами, такими как встряхивание дерева, отложенная загрузка модулей и ускорение этих общих оптимизаций с помощью сети cdn extrens. Даже в проекте vue-cli мы можем использовать команду --modern для генерации нового и старого кода браузера для оптимизации программы.

На самом деле кэширование должно быть одним из самых эффективных способов улучшения веб-приложений, особенно когда пользователи ограничены скоростью Интернета. Улучшите реакцию системы и уменьшите потребление сети. Конечно, чем ближе контент к пользователю, тем быстрее и эффективнее будет кеш.

На стороне клиента у нас есть много способов кэширования данных и ресурсов, таких как стандартный кэш браузера и текущий горячий сервис-воркер. Однако они больше подходят для кэширования статического контента. Например html, js, css и картинки и другие файлы. Для кэширования системных данных я использую другое решение.

Затем я представлю различные схемы кэширования запросов API, которые я применил в проекте, от простых до сложных.

Вариант 1 Кэш данных

Простой кеш данных, получайте данные по первому запросу, затем используйте данные и больше не запрашивайте внутренний API.
код показывает, как показано ниже:

const dataCache = new Map()

async getWares() {
    let key = 'wares'
    // 从data 缓存中获取 数据
    let data = dataCache.get(key)
    if (!data) {
        // 没有数据请求服务器
        const res = await request.get('/getWares')
        
        // 其他操作
        ...
        data = ...

        // 设置数据缓存
        dataCache.set(key, data)

    }
    return data
} 

В первой строке используется больше es6 Map, если случай не очень понимает карту, можно обратиться кEcmascript 6 карта и установить стартерилиExploring ES6Введение map и set можно понимать здесь как структуру хранения пары ключ-значение.

После этого код использует асинхронные функции, чтобы сделать асинхронные операции более удобными. вы можете обратиться кНачало работы с асинхронными функциями ECMAScript 6учиться или закреплять знания.

Сам код прост для понимания, он использует объект Map для кэширования данных, а затем вызывается для получения данных из объекта Map. Для очень простых бизнес-сценариев этот код можно использовать напрямую.

Метод вызова:

getWares().then( ... )
// 第二次调用 取得先前的data
getWares().then( ... )

Вариант 2 обещает кеш

Вариант 1 сам по себе недостаточен. Потому что, если вы рассматриваете два или более вызовов этого API одновременно, будет сделан второй запрос к API, потому что запрос не возвращается. Конечно, если добавить в систему единый фреймворк источника данных вроде vuex и redux, такой проблемы не возникнет, но иногда мы хотим вызывать апи отдельно в каждом сложном компоненте, но не хотим обмениваться данными между компонентами когда происходит этот сценарий.

const promiseCache = new Map()

getWares() {
    const key = 'wares'
    let promise = promiseCache.get(key);
    // 当前promise缓存中没有 该promise
    if (!promise) {
        promise = request.get('/getWares').then(res => {
            // 对res 进行操作
            ...
        }).catch(error => {
            // 在请求回来后,如果出现问题,把promise从cache中删除 以避免第二次请求继续出错S
            promiseCache.delete(key)
            return Promise.reject(error)
        })
        promiseCache.set(key, promise)
    }
    // 返回promise
    return promise
}

Этот код позволяет избежать проблемы нескольких одновременных запросов в схеме 1. В то же время промис удаляется в случае ошибки в бэкенде, и не будет проблем с тем, что кешированный промис продолжает работать неправильно.

Метод вызова:

getWares().then( ... )
// 第二次调用 取得先前的promise
getWares().then( ... )

Вариант 3 Кэш с несколькими обещаниями

Решение состоит в том, чтобы возвращать данные одновременно, когда одновременно требуется более одного запроса API, если в определенном API возникает ошибка. Ни один из них не возвращает правильные данные.

const querys ={
    wares: 'getWares',
    skus: 'getSku'
}
const promiseCache = new Map()

async queryAll(queryApiName) {
    // 判断传入的数据是否是数组
    const queryIsArray = Array.isArray(queryApiName)
    // 统一化处理数据,无论是字符串还是数组均视为数组
    const apis = queryIsArray ? queryApiName : [queryApiName]
    
    // 获取所有的 请求服务
    const promiseApi = []

    apis.forEach(api => {
        // 利用promise 
        let promise = promiseCache.get(api)

        if (promise) {
            // 如果 缓存中有,直接push
            promise.push(promise)
        } else {
             promise = request.get(querys[api]).then(res => {
                // 对res 进行操作
                ...
                }).catch(error => {
                // 在请求回来后,如果出现问题,把promise从cache中删除
                promiseCache.delete(api)
                return Promise.reject(error)
            })
            promiseCache.set(api, promise)
            promiseCache.push(promise)
        }
    })
    return Promise.all(promiseApi).then(res => {
        // 根据传入的 是字符串还是数组来返回数据,因为本身都是数组操作
        // 如果传入的是字符串,则需要取出操作
        return queryIsArray ? res : res[0]
    })
}

Эта схема представляет собой способ получения данных с нескольких серверов одновременно. Несколько данных могут быть получены одновременно для работы, и не будет ошибок из-за проблем с одними данными.

метод вызова

queryAll('wares').then( ... )
// 第二次调用 不会去取 wares,只会去skus
queryAll(['wares', 'skus']).then( ... )

Вариант 4. Добавить кеш, связанный со временем

Кэш часто вреден.Если мы знаем, что данные были изменены, мы можем удалить кеш напрямую.В это время мы можем сделать запрос к серверу, вызвав метод. Таким образом, мы избегаем отображения старых данных во внешнем интерфейсе. Но мы можем не работать с данными в течение определенного периода времени, тогда старые данные всегда будут существовать в это время, тогда нам лучше установить время для удаления данных.
Это решение использует постоянные данные класса для кэширования данных и добавляет просроченные данные о продолжительности и параметризацию.
код показывает, как показано ниже: Сначала определите постоянный класс, который может хранить обещания или данные.

class ItemCache() {
    construct(data, timeout) {
        this.data = data
        // 设定超时时间,设定为多少秒
        this.timeout = timeout
        // 创建对象时候的时间,大约设定为数据获得的时间
        this.cacheTime = (new Date()).getTime()
    }
}

Затем мы определяем этот кеш данных. Мы используем Map в основном тот же API

class ExpriesCache {
    // 定义静态数据map来作为缓存池
    static cacheMap =  new Map()

    // 数据是否超时
    static isOverTime(name) {
        const data = ExpriesCache.cacheMap.get(name)
        
        // 没有数据 一定超时
        if (!data) return true

        // 获取系统当前时间戳
        const currentTime = (new Date()).getTime()        
        
        // 获取当前时间与存储时间的过去的秒数
        const overTime = (currentTime - data.cacheTime) / 1000
        
        // 如果过去的秒数大于当前的超时时间,也返回null让其去服务端取数据
        if (Math.abs(overTime) > data.timeout) {
            // 此代码可以没有,不会出现问题,但是如果有此代码,再次进入该方法就可以减少判断。
            ExpriesCache.cacheMap.delete(name)
            return true
        }

        // 不超时
        return false
    }

    // 当前data在 cache 中是否超时
    static has(name) {
        return !ExpriesCache.isOverTime(name)
    }

    // 删除 cache 中的 data
    static delete(name) {
        return ExpriesCache.cacheMap.delete(name) 
    }

    // 获取
    static get(name) {
        const isDataOverTiem = ExpriesCache.isOverTime(name)
        //如果 数据超时,返回null,但是没有超时,返回数据,而不是 ItemCache 对象
        return isDataOverTiem ? null : ExpriesCache.cacheMap.get(name).data
    }

    // 默认存储20分钟
    static set(name, data, timeout = 1200) {
        // 设置 itemCache
        const itemCache = mew ItemCache(data, timeout)
        //缓存
        ExpriesCache.cacheMap.set(name, itemCache)
    }
}

На данный момент класс данных и класс операции определены, и мы можем определить их на уровне API.

// 生成key值错误
const generateKeyError = new Error("Can't generate key from name and argument")

// 生成key值
function generateKey(name, argument) {
    // 从arguments 中取得数据然后变为数组
    const params = Array.from(argument).join(',')
    
    try{
        // 返回 字符串,函数名 + 函数参数
        return `${name}:${params}`
    }catch(_) {
        // 返回生成key错误
        return generateKeyError
    }
}

async getWare(params1, params2) {
    // 生成key
    const key = generateKey('getWare', [params1, params2]) 
    // 获得数据
    let data = ExpriesCache.get(key)
    if (!data) {
        const res = await request('/getWares', {params1, params2})
        // 使用 10s 缓存,10s之后再次get就会 获取null 而从服务端继续请求
        ExpriesCache.set(key, res, 10)
    }
    return data
}

В этой схеме используется способ кеширования с разным временем истечения и параметрами API. Он уже может соответствовать большинству бизнес-сценариев.

метод вызова

getWares(1,2).then( ... )
// 第二次调用 取得先前的promise
getWares(1,2).then( ... )
// 不同的参数,不取先前promise
getWares(1,3).then( ... )

Вариант 5 на основе модификатора Вариант 4

Это то же самое, что и решение в четвертом решении, но делается на основе декоратора. код показывает, как показано ниже:

// 生成key值错误
const generateKeyError = new Error("Can't generate key from name and argument")

// 生成key值
function generateKey(name, argument) {
    // 从arguments 中取得数据然后变为数组
    const params = Array.from(argument).join(',')
    try{
        // 返回 字符串
        return `${name}:${params}`
    }catch(_) {
        return generateKeyError
    }
}

function decorate(handleDescription, entryArgs) {
    // 判断 当前 最后数据是否是descriptor,如果是descriptor,直接 使用
    // 例如 log 这样的修饰器
    if (isDescriptor(entryArgs[entryArgs.length - 1])) {
        return handleDescription(...entryArgs, [])
    } else {
        // 如果不是
        // 例如 add(1) plus(20) 这样的修饰器
        return function() {
            return handleDescription(...Array.protptype.slice.call(arguments), entryArgs)
        }
    }
}

function handleApiCache(target, name, descriptor, ...config) {
    // 拿到函数体并保存
    const fn = descriptor.value
    // 修改函数体
    descriptor.value = function () { 
        const key =  generateKey(name, arguments)
        // key无法生成,直接请求 服务端数据
        if (key === generateKeyError)  {
            // 利用刚才保存的函数体进行请求
            return fn.apply(null, arguments)
        }
        let promise = ExpriesCache.get(key)
        if (!promise) {
            // 设定promise
            promise = fn.apply(null, arguments).catch(error => {
                 // 在请求回来后,如果出现问题,把promise从cache中删除
                ExpriesCache.delete(key)
                // 返回错误
                return Promise.reject(error)
            })
            // 使用 10s 缓存,10s之后再次get就会 获取null 而从服务端继续请求
            ExpriesCache.set(key, promise, config[0])
        }
        return promise 
    }
    return descriptor;
}

// 制定 修饰器
function ApiCache(...args) {
    return decorate(handleApiCache, args)
}

На этом этапе мы будем использовать класс для кэширования API.

class Api {
    // 缓存10s
    @ApiCache(10)
    // 此时不要使用默认值,因为当前 修饰器 取不到
    getWare(params1, params2) {
        return request.get('/getWares')
    }
}

Поскольку функции имеют продвижение функций, нет возможности использовать функции в качестве декораторов.
Например:

var counter = 0;

var add = function () {
  counter++;
};

@add
function foo() {
}

Намерение кода состоит в том, что счетчик равен 1 после выполнения, но фактический результат состоит в том, что счетчик равен 0. Из-за продвижения функции фактически выполняемый код выглядит следующим образом

@add
function foo() {
}

var counter;
var add;

counter = 0;

add = function () {
  counter++;
};

Таким образом, нет возможности использовать декораторы для функций. конкретная ссылкаНачало работы с декораторами ECMAScript 6
Этот способ написания прост и не оказывает большого влияния на бизнес-уровень. Однако время кэширования не может быть динамически изменено.

метод вызова

getWares(1,2).then( ... )
// 第二次调用 取得先前的promise
getWares(1,2).then( ... )
// 不同的参数,不取先前promise
getWares(1,3).then( ... )

Суммировать

Здесь также в основном представлен механизм кэширования и сценарии API, которые могут в основном завершить большую часть бизнес-кэширования данных.Вот я также хочу спросить всех, есть ли лучшее решение, или есть в этом блоге Что не так, добро пожаловать чтобы исправить меня, спасибо всем здесь.
В то же время здесь также много незавершенной работы, которую, возможно, продолжат улучшать в более поздних блогах.