很多团队接入 Redis 的第一站,就是缓存。
最经典模式是 Cache Aside:
请求进来
↓
先查 Redis
↓
命中就直接返回
↓
没命中再查数据库
↓
把结果回填 Redis
↓
返回给调用方一个极简伪代码:
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. 误以为“缓存越多越好”
不是。缓存命中率、内存成本、失效复杂度、回源压力,都要一起看。