API调用结果缓存：让系统更快更省的实用技巧

为什么需要缓存API返回的数据

你有没有遇到过这种情况：每次打开一个应用，列表都要重新加载一遍，等得手指都点冒烟了？其实很多数据根本没变，比如天气信息、商品价格、用户资料。反复请求同一个API，不仅慢，还浪费服务器资源。

这时候，API调用结果缓存就派上用场了。简单说，就是把上次请求的结果存下来，下次要用的时候先看看有没有现成的，有的话直接拿来用，省时又省力。

缓存能解决哪些实际问题

举个例子，你开发一个新闻App，首页要展示热门文章。这些内容一小时内不会变，但每分钟有几万人访问。如果每个人都去数据库查一遍，数据库早就扛不住了。但如果把接口返回的结果缓存60秒，同一时间段内后续请求直接读缓存，压力立马小一大截。

再比如内部管理系统，员工资料接口被多个模块调用。一个人的信息不会频繁变动，每次点开不同页面都去请求一次，纯属浪费。本地缓存一份，打开新页面秒出数据，体验也顺滑多了。

常见的缓存方式

最简单的就是在内存里存个对象。比如用JavaScript写个小型缓存：

const cache = {};

function getCachedAPI(url, fetchFn, ttl = 5 * 60 * 1000) {
  const item = cache[url];
  if (item && Date.now() < item.timestamp + ttl) {
    return Promise.resolve(item.data);
  }
  
  return fetchFn().then(data => {
    cache[url] = { data, timestamp: Date.now() };
    return data;
  });
}

上面这段代码给每个请求加了个有效期，比如5分钟。这段时间内重复调用，直接返回缓存结果，避免重复请求。

如果是服务端场景，可以用Redis这种外部缓存系统。好处是多实例共享，重启不丢（配合持久化），还能设置自动过期。

SET api:user:123 "{\"name\":\"张三\",'dept':\"技术部\"}" EX 300

这条Redis命令就把用户数据缓存了300秒，下次查询先看key是否存在，存在就直接取，不存在再查数据库。

什么时候不该用缓存

不是所有接口都适合缓存。比如下单结果、支付状态、实时聊天消息，这些数据变化频繁，延迟敏感，缓存可能让你看到过时信息。

另外，用户私有数据要注意隔离。不能把A用户的订单缓存，错当成B的返回了。缓存key最好带上用户ID或身份标识，避免冲突。

还有就是缓存雪崩问题。别给所有数据设同一个过期时间，否则一到时间点全失效，请求全打到后端，容易压垮服务。可以加个随机偏移，错开失效时间。

小改动带来大提升

加个缓存不一定非得大动干戈。从最关键的高频接口开始，比如首页数据、配置项、公共字典。哪怕只缓存几十秒，也能明显降低后端压力，响应速度肉眼可见地变快。

别小看这一步，很多性能问题，其实就是重复干活造成的。学会让系统“记住”结果，而不是每次都从头来过，这才是聪明的做法。