设计一个支持并发的前端接口缓存

news2024/12/23 7:31:57

目录​​​​​​​

缓存池

并发缓存

问题

思考

优化🤔

总结

最后


缓存池

        缓存池不过就是一个map,存储接口数据的地方,将接口的路径和参数拼到一块作为key,数据作为value存起来罢了,这个咱谁都会。

const cacheMap = new Map();

封装一下调用接口的方法,调用时先走咱们缓存数据。

import axios, { AxiosRequestConfig } from 'axios'

// 先来一个简简单单的发送
export function sendRequest(request: AxiosRequestConfig) {
  return axios(request)
}

然后加上咱们的缓存

import axios, { AxiosRequestConfig } from 'axios'
import qs from 'qs'

const cacheMap = new Map()

interface MyRequestConfig extends AxiosRequestConfig {
  needCache?: boolean
}

// 这里用params是因为params是 GET 方式传的参数,我们的缓存一般都是 GET 接口用的
function generateCacheKey(config: MyRequestConfig) {
  return config.url + '?' + qs.stringify(config.params)
}

export function sendRequest(request: MyRequestConfig) {
  const cacheKey = generateCacheKey(request)
  // 判断是否需要缓存,并且缓存池中有值时,返回缓存池中的值
  if (request.needCache && cacheMap.has(cacheKey)) {
    return Promise.resolve(cacheMap.get(cacheKey))
  }
  return axios(request).then((res) => {
    // 这里简单判断一下,200就算成功了,不管里面的data的code啥的了
    if (res.status === 200) {
      cacheMap.set(cacheKey, res.data)
    }
    return res
  })
}

然后调用

const getArticleList = (params: any) =>
  sendRequest({
    needCache: true,
    url: '/article/list',
    method: 'get',
    params
  })

getArticleList({
  page: 1,
  pageSize: 10
}).then((res) => {
  console.log(res)
})

        这个部分就很简单,我们在调接口时给一个needCache的标记,然后调完接口如果成功的话,就会将数据放到cacheMap中去,下次再调用的话,就直接返回缓存中的数据。

并发缓存

        上面的虽然看似实现了缓存,不管我们调用几次,都只会发送一次请求,剩下的都会走缓存。但是真的是这样吗?

getArticleList({
  page: 1,
  pageSize: 10
}).then((res) => {
  console.log(res)
})
getArticleList({
  page: 1,
  pageSize: 10
}).then((res) => {
  console.log(res)
})

        其实这样,就可以测出,我们的虽然设计了缓存,但是请求还是发送了两次,这是因为我们第二次请求发出时,第一次请求还没完成,也就没给缓存池里放数据,所以第二次请求没命中缓存,也就又发了一次。

问题

        那么,有没有一种办法让第二次请求等待第一次请求调用完成,然后再一块返回呢?

思考

        有了!我们写个定时器就好了呀,比如我们可以给第二次请求加个定时器,定时器时间到了再去cacheMap中查一遍有没有缓存数据,没有的话可能是第一个请求还没好,再等几秒试试!

        可是这样的话,第一个请求的时候也会在原地等呀!😒

        那这样的话,让第一个请求在一个地方贴个告示不就好了,就像上厕所的时候在门口挂个牌子一样!😎

// 存储缓存当前状态,相当于挂牌子的地方
const statusMap = new Map<string, 'pending' | 'complete'>();

export function sendRequest(request: MyRequestConfig) {
  const cacheKey = generateCacheKey(request)

  // 判断是否需要缓存
  if (request.needCache) {
    if (statusMap.has(cacheKey)) {
      const currentStatus = statusMap.get(cacheKey)

      // 判断当前的接口缓存状态,如果是 complete ,则代表缓存完成
      if (currentStatus === 'complete') {
        return Promise.resolve(cacheMap.get(cacheKey))
      }

      // 如果是 pending ,则代表正在请求中,这里就等个三秒,然后再来一次看看情况
      if (currentStatus === 'pending') {
        return new Promise((resolve, reject) => {
          setTimeout(() => {
            sendRequest(request).then(resolve, reject)
          }, 3000)
        })
      }
    }

    statusMap.set(cacheKey, 'pending')
  }

  return axios(request).then((res) => {
    // 这里简单判断一下,200就算成功了,不管里面的data的code啥的了
    if (res.status === 200) {
      statusMap.set(cacheKey, 'complete')
      cacheMap.set(cacheKey, res)
    }
    return res
  })
}

试试效果

getArticleList({
    page: 1,
    pageSize: 10
}).then((res) => {
    console.log(res)
})
getArticleList({
    page: 1,
    pageSize: 10
}).then((res) => {
    console.log(res)
})

成了!这里真的做到了,可以看到我们这里打印了两次,但是只发了一次请求。

优化🤔

        可是用setTimeout等待还是不太优雅,如果第一个请求能在3s以内完成还行,用户等待的时间还不算太久,还能忍受。可如果是3.1s的话,第二个接口用户可就白白等了6s之久,那么,有没有一种办法,能让第一个接口完成后,接着就通知第二个接口返回数据呢?

        等待,通知,这种场景我们写代码用的最多的就是回调了,但是这次用的是promise啊,而且还是毫不相干的两个promise。等等!callbackpromisepromise本身就是callback实现的!promisethen会在resole被调用时调用,这样的话,我们可以将第二个请求的resole放在一个callback里,然后在第一个请求完成的时候,调用这个callback!🥳

// 定义一下回调的格式
interface RequestCallback {
  onSuccess: (data: any) => void
  onError: (error: any) => void
}

// 存放等待状态的请求回调
const callbackMap = new Map<string, RequestCallback[]>()

export function sendRequest(request: MyRequestConfig) {
  const cacheKey = generateCacheKey(request)

  // 判断是否需要缓存
  if (request.needCache) {
    if (statusMap.has(cacheKey)) {
      const currentStatus = statusMap.get(cacheKey)

      // 判断当前的接口缓存状态,如果是 complete ,则代表缓存完成
      if (currentStatus === 'complete') {
        return Promise.resolve(cacheMap.get(cacheKey))
      }

      // 如果是 pending ,则代表正在请求中,这里放入回调函数
      if (currentStatus === 'pending') {
        return new Promise((resolve, reject) => {
          if (callbackMap.has(cacheKey)) {
            callbackMap.get(cacheKey)!.push({
              onSuccess: resolve,
              onError: reject
            })
          } else {
            callbackMap.set(cacheKey, [
              {
                onSuccess: resolve,
                onError: reject
              }
            ])
          }
        })
      }
    }

    statusMap.set(cacheKey, 'pending')
  }

  return axios(request).then(
    (res) => {
      // 这里简单判断一下,200就算成功了,不管里面的data的code啥的了
      if (res.status === 200) {
        statusMap.set(cacheKey, 'complete')
        cacheMap.set(cacheKey, res)
      } else {
        // 不成功的情况下删掉 statusMap 中的状态,能让下次请求重新请求
        statusMap.delete(cacheKey)
      }
      // 这里触发resolve的回调函数
      if (callbackMap.has(cacheKey)) {
        callbackMap.get(cacheKey)!.forEach((callback) => {
          callback.onSuccess(res)
        })
        // 调用完成之后清掉,用不到了
        callbackMap.delete(cacheKey)
      }
      return res
    },
    (error) => {
      // 不成功的情况下删掉 statusMap 中的状态,能让下次请求重新请求
      statusMap.delete(cacheKey)
      // 这里触发reject的回调函数
      if (callbackMap.has(cacheKey)) {
        callbackMap.get(cacheKey)!.forEach((callback) => {
          callback.onError(error)
        })
        // 调用完成之后也清掉
        callbackMap.delete(cacheKey)
      }
      // 这里要返回 Promise.reject(error),才能被catch捕捉到
      return Promise.reject(error)
    }
  )
}

        在判断到当前请求状态是pending时,将promiseresolereject放入回调队列中,等待被触发调用。然后在请求完成时,触发对应的请求队列。

试一下

getArticleList({
    page: 1,
    pageSize: 10
}).then((res) => {
    console.log(res)
})
getArticleList({
    page: 1,
    pageSize: 10
}).then((res) => {
    console.log(res)
})

OK,完成了。

再试一下失败的时候

getArticleList({
    page: 1,
    pageSize: 10
}).then(
    (res) => {
      console.log(res)
    },
    (error) => {
      console.error(error)
    }
)
getArticleList({
    page: 1,
    pageSize: 10
}).then(
    (res) => {
      console.log(res)
    },
    (error) => {
      console.error(error)
    }
)

        OK,两个都失败了。(但是这里的error2早于error1打印,你知道是啥原因吗?🤔)

总结

    promise封装并发缓存到这里就结束啦,不过看到这里你可能会觉着没啥用处,但是其实这也是我碰到的一个需求才延申出来的,当时的场景是一个页面里有好几个下拉选择框,选项都是接口提供的常量。但是只接口提供了一个接口返回这些常量,前端拿到以后自己再根据类型挑出来,所以这种情况我们肯定不能每个下拉框都去调一次接口,只能是寄托缓存机制了。

        这种写法,在另一种场景下也很好用,比如将需要用户操作的流程封装成promise。例如,A页面点击A按钮,出现一个B弹窗,弹窗里有B按钮,用户点击B按钮之后关闭弹窗,再弹出C弹窗C按钮,点击C之后流程完成,这种情况就很适合将每个弹窗里的操作流程都封装成一个promise,最外面的A页面只需要连着调用这几个promise就可以了,而不需要维护控制这几个弹窗显示隐藏的变量了。

放一下全部代码

import axios, { AxiosRequestConfig } from 'axios'
import qs from 'qs'

// 存储缓存数据
const cacheMap = new Map()

// 存储缓存当前状态
const statusMap = new Map<string, 'pending' | 'complete'>()

// 定义一下回调的格式
interface RequestCallback {
  onSuccess: (data: any) => void
  onError: (error: any) => void
}

// 存放等待状态的请求回调
const callbackMap = new Map<string, RequestCallback[]>()

interface MyRequestConfig extends AxiosRequestConfig {
  needCache?: boolean
}

// 这里用params是因为params是 GET 方式穿的参数,我们的缓存一般都是 GET 接口用的
function generateCacheKey(config: MyRequestConfig) {
  return config.url + '?' + qs.stringify(config.params)
}

export function sendRequest(request: MyRequestConfig) {
  const cacheKey = generateCacheKey(request)

  // 判断是否需要缓存
  if (request.needCache) {
    if (statusMap.has(cacheKey)) {
      const currentStatus = statusMap.get(cacheKey)

      // 判断当前的接口缓存状态,如果是 complete ,则代表缓存完成
      if (currentStatus === 'complete') {
        return Promise.resolve(cacheMap.get(cacheKey))
      }

      // 如果是 pending ,则代表正在请求中,这里放入回调函数
      if (currentStatus === 'pending') {
        return new Promise((resolve, reject) => {
          if (callbackMap.has(cacheKey)) {
            callbackMap.get(cacheKey)!.push({
              onSuccess: resolve,
              onError: reject
            })
          } else {
            callbackMap.set(cacheKey, [
              {
                onSuccess: resolve,
                onError: reject
              }
            ])
          }
        })
      }
    }

    statusMap.set(cacheKey, 'pending')
  }

  return axios(request).then(
    (res) => {
      // 这里简单判断一下,200就算成功了,不管里面的data的code啥的了
      if (res.status === 200) {
        statusMap.set(cacheKey, 'complete')
        cacheMap.set(cacheKey, res)
      } else {
        // 不成功的情况下删掉 statusMap 中的状态,能让下次请求重新请求
        statusMap.delete(cacheKey)
      }
      // 这里触发resolve的回调函数
      if (callbackMap.has(cacheKey)) {
        callbackMap.get(cacheKey)!.forEach((callback) => {
          callback.onSuccess(res)
        })
        // 调用完成之后清掉,用不到了
        callbackMap.delete(cacheKey)
      }
      return res
    },
    (error) => {
      // 不成功的情况下删掉 statusMap 中的状态,能让下次请求重新请求
      statusMap.delete(cacheKey)
      // 这里触发reject的回调函数
      if (callbackMap.has(cacheKey)) {
        callbackMap.get(cacheKey)!.forEach((callback) => {
          callback.onError(error)
        })
        // 调用完成之后也清掉
        callbackMap.delete(cacheKey)
      }
      return Promise.reject(error)
    }
  )
}

const getArticleList = (params: any) =>
  sendRequest({
    needCache: true,
    baseURL: 'http://localhost:8088',
    url: '/article/blogList',
    method: 'get',
    params
  })

export function testApi() {
  getArticleList({
    page: 1,
    pageSize: 10
  }).then(
    (res) => {
      console.log(res)
    },
    (error) => {
      console.error('error1:', error)
    }
  )
  getArticleList({
    page: 1,
    pageSize: 10
  }).then(
    (res) => {
      console.log(res)
    },
    (error) => {
      console.error('error2:', error)
    }
  )
}

最后

        对请求结果是否成功那里处理的比较简陋,项目里用到的话根据自己情况来。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/597212.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

DTU和MQTT网关优缺点

目前市面上有两种设备实现Modbus转MQTT网关。网关式、DTU式。 钡铼技术网关内部进行转换 网关式 优点&#xff1a; 1、通讯模块和MCU分开&#xff0c;通讯模块只做通讯功能&#xff0c;协议转换有单独主控MCU&#xff0c;“硬转换”&#xff1b; 2、数据点是通过映射到主控…

【严重】GitLab 存在代码执行漏洞

漏洞描述 GitLab 是一款基于Git的代码托管、版本控制、协作开发平台。 GitLab CE/EE 15.4 至 15.9.6 版本&#xff0c;15.10 至 15.10.5 版本和 15.11 至 15.11.1 版本存在代码执行漏洞。在某些条件下&#xff0c;实例上的任何GitLab用户都可以使用GraphQL端点将恶意运行程序…

HTML框架-----标签(下)

目录 前言&#xff1a; 5.容器标签 效果&#xff1a;​编辑 6.列表标签 (1)无序 &#xff08;2&#xff09;有序 7.图片标签 8.超链接标签 &#xff08;1&#xff09;链接资源 &#xff08;2&#xff09;超链接锚点 前言&#xff1a; 今天我们接着来继续学习html的标签&am…

五重要性能测试指标揭秘!并发数、TPS、QPS、响应时间和资源利用率,了解性能瓶颈,优化系统高负载下的处理能力

目录 前言&#xff1a; 1. 并发数 2. TPS 3. QPS 4. 响应时间 5. 资源利用率 总结 前言&#xff1a; 在高并发的场景下&#xff0c;我们需要考虑如何优化我们的应用程序&#xff0c;以确保它可以承受大量的请求并且在给定时间内响应。对于这个问题&#xff0c;性能测试就…

字节码文件结构

目录 1、概述 2、JVM的两个无关性 3、Class字节码文件的结构 1、基本存储单位 2、字节码文件数据结构 3、Class文件格式 4、魔数与Class文件的版本 5、常量池 6、访问标志 7、类索引、父类索引与接口索引集合 8、字段表集合 9、方法表集合 10、属性表集合 11、总…

centos7.9升级rockylinux8.8

前言 查看centos的版本 &#xff0c;我这台服务器是虚拟机,下面都是模拟实验 升级前一定要把服务器上配置文件&#xff0c;数据等进行备份 [rootlocalhost ~]#cat /etc/redhat-release CentOS Linux release 7.9.2009 (Core) [rootlocalhost ~]#uname -a Linux jenkins_ser…

Ubuntu常见基本问题

系列文章目录 文章目录 系列文章目录一、复制粘贴问题二、无法全屏问题三、设置为中文四、时间同步问题1、选择时区2、同步网络时间 一、复制粘贴问题 开启终端&#xff1a;ctrlaltt卸载已有工具 sudo apt-get autoremove open-vm-tools安装工具open-vm-tools sudo apt-get …

echarts的y轴数据显示过长占不下,内容截取,鼠标hover上去显示全部

初始效果&#xff1a; 优化后的效果&#xff1a; 优化点&#xff1a;控制了y轴显示字数&#xff0c;鼠标hover上去显示全部 主要实现思路参考了这位同学的文章&#xff1a;https://www.cnblogs.com/liuboren/p/9040622.html 我是用vue实现的&#xff0c;因为我需要一个页面中…

各算法/协议知识理论笔记(fpga)

一、利用fifo对3行数据求和 需要2个fifo保存第0行和第1行的数据&#xff0c;如下图 比如有20行数据&#xff0c;则将一行一行的输给fifo2, fifo2出来的数据再给fifo1.当fifo和fifo1有数据时&#xff0c;在准备给 fifo2输入新的一行数据时&#xff0c;同时读出fifo2&#xff0c;…

Linux进程间通信(信号)

信号发送 信号是 Linux 系统响应某些条件而产生的一个事件&#xff0c;接收到该信号的进程会执行相应的操作。 信号的产生有三种方式&#xff1a; &#xff08;1)由硬件产生&#xff0c;如从键盘输入 CtrlC 可以终止当前进程 &#xff08;2)由其他进程发送&#xff0c;如可在 …

PostgreSQL修炼之道之高可用性方案设计(十七)

目录 20 高可用性方案设计&#xff08;二&#xff09; 20.2 基于共享存储的高可用方案 20.2.1 SAN存储的方案 20.2.2 DRBD的方案 20.3 WAL日志同步或流复制同步的方案 20.3.1 持续复制归档的standby的方法 20.3.2 异步流复制的方案 20.3.3 基于同步流复制方案 20.4 基于…

国内外低代码开发平台发展情况如何?

国内外低代码开发平台发展情况如何&#xff1f;之前有些过很多关于低代码的内容&#xff0c;这篇就来详细梳理下国内外低代码开发平台发展现状。 关于低代码解读看这篇>>什么是低代码&#xff08;Low-Code&#xff09;&#xff1f;关于低代码平台看这篇>>主流的开…

业务高速增长,如祺出行如何用腾讯云消息队列 RocketMQ 应对挑战

导语 作为广汽集团旗下的智慧出行平台&#xff0c;如祺出行上线四年时间&#xff0c;用户规模和订单量保持高速增长。在过去的2022年&#xff0c;如祺出行平台累计注册用户突破1800万&#xff0c;同比增长64%&#xff0c;年度订单总量超7000万&#xff0c;同比增长52%。 高速…

【MCS-51】串行I/O接口及其通信

我们知道MCS-51中有很多的引脚&#xff0c;这些引脚很多一般都是用作输入或者输出口&#xff0c;其中有两个引脚P3.0和P3.1比较特殊&#xff0c;我们常将其用作串行通信的数据发送和接收端TXD、RXD。 目录 &#x1f431;通信方式 &#x1f431;串行通信的传输方式和数据通信…

python笔记17_实例演练_二手车折旧分析p2

…… 书接上文 4.车辆等级维度 探查车龄为5年的车辆&#xff0c;折旧价值与车辆等级的关系。 # 筛选出车龄为5的数据创建新表 data_age5 data[data[age] 5] data_age5 # 分组聚合计算均值 data_car_level data_age5.groupby(car_level_name)[lowest_price].mean().reset…

16.2:岛屿数量问题

文章目录 岛屿数量问题方法一&#xff1a;采用递归的方法方法二&#xff1a;使用并查集的方法&#xff08;map&#xff09;方法三&#xff1a;使用并查集的方法&#xff08;数组&#xff09; 岛屿数量问题 测试链接&#xff1a;https://leetcode.com/problems/number-of-islan…

大数据:分布式计算,MapReduce,hadoop的计算组件,hive是sql分布式计算框架,底层就是基于MapReduce的

大数据&#xff1a;分布式计算&#xff0c;MapReduce&#xff0c;hadoop的计算组件&#xff0c;hive是sql分布式计算框架&#xff0c;底层就是基于MapReduce的 2022找工作是学历、能力和运气的超强结合体&#xff0c;遇到寒冬&#xff0c;大厂不招人&#xff0c;可能很多算法学…

【C++】一文带你入门 STL

一 STL 组成 graph LRA[STL] --- B[容器 container]A --- C[配接器 adapter]A --- D[迭代器 iterator]A --- E[仿函数 function]A --- F[算法 algorithm]A --- G[空间配置器 allocator]二 常用容器 容器简介 下面我们来简单看一下这些容器的常用接口的使用&#xff0c;并分析…

更新中-深度学习实战中遇到的一些概念+少量代码

onnx ONNX 是一种用于机器学习模型的开放式表示格式&#xff0c;它可以让不同的深度学习框架之间共享模型。 import onnxruntime # 加载模型 session onnxruntime.InferenceSession(model.onnx) # 运行模型。第一个参数是输出变量列表&#xff0c;不指定的话返回所有值 outp…

ESP8266使用MicroPython接入ThingsBoard

1、概述 我们老大当初叫我学习microPython,这个可以直接将代码发到板子上,然后就可以跑,就相当于设备业务代码由我们来写,不仅仅是让嵌入式来写,嵌入式做的就是封装函数,我们可以调用.最终这个还是实现了,但是没有推广. 2、设备 我自己购买的设备是ESP8266,某宝上购买的,mic…