全书目录

第九篇:Redis 完全指南 —— 软件城市实时调度中心宇宙

第九章:缓存 —— Redis 最常见的角色,但也最容易被写烂

1 分钟 331 字 第 212 / 962 个阅读单元

很多团队接入 Redis 的第一站,就是缓存。

最经典模式是 Cache Aside

text
请求进来
  ↓
先查 Redis
  ↓
命中就直接返回
  ↓
没命中再查数据库
  ↓
把结果回填 Redis
  ↓
返回给调用方

一个极简伪代码:

ts
async function getProduct(productId: string) {
  const cacheKey = `cache:product:${productId}`;

  const cached = await redis.get(cacheKey);
  if (cached) {
    return JSON.parse(cached);
  }

  const product = await db.product.findUnique({ where: { id: productId } });
  if (!product) return null;

  await redis.set(cacheKey, JSON.stringify(product), { EX: 300 });
  return product;
}
#缓存最容易犯的 4 个错
#1. 只会“加缓存”,不会“设计失效”

缓存不是永远正确的数据源。你必须明确:

  • TTL 多长
  • 更新后怎么删
  • 哪些页面允许旧数据
  • 哪些接口不能容忍脏读
#2. 把 Redis 当永久真相源,却不做持久化和备份设计

如果这是纯缓存,可以。 如果这是重要状态,不够。

#3. 忽略缓存击穿、穿透、雪崩

你至少要知道这些问题的存在:

  • 击穿:一个热 key 过期瞬间大量请求打到数据库
  • 穿透:请求的根本就是不存在的数据
  • 雪崩:一批 key 同时过期
#4. 误以为“缓存越多越好”

不是。缓存命中率、内存成本、失效复杂度、回源压力,都要一起看。