在每分钟数百万请求下，如何用缓存削减 DB 负载？

Question

IT Interview Practice · Accepted Answer

在 DB 前面放一层 **cache-aside**（Redis/Memcached），使读取命中内存，给条目设置 **TTL** 并**在写入时使其失效（invalidate）**，加入**踩踏保护（stampede protection）**，使一个冷键无法对 DB 释放一场惊群（thundering herd），并把**热点键（hot keys）**分散到多个 replica 上，使一个热门键不会烧毁单个节点。

```text
                 ┌── hit ──▶ return value
request ──▶ cache│
                 └── miss ─▶ lock ─▶ DB read ─▶ set(TTL) ─▶ return
                              │
                    (only ONE miss populates; others wait)
DB writes ──▶ invalidate/update key
```

## Cache-aside 与 read-through

在 **cache-aside** 中，应用检查缓存；未命中时它自己读 DB 并填充缓存。在 **read-through** 中，缓存库替你做这件事。无论哪种方式，目标都一样：把一次 5ms 的 DB 查询变成一次 0.2ms 的内存查找，因此一个 95% 命中率的缓存能把 DB 读流量削减 **20 倍**。在每分钟数百万请求下，DB 根本无法服务每一次读——正是缓存让这些数字成立。

## TTL + 失效

让缓存保持新鲜有两种方式，而你通常两者都需要。**TTL** 限定陈旧程度——条目在 N 秒后过期，使错误数据自愈。**显式失效（Explicit invalidation）**在写入时删除/更新键，用于无法等待 TTL 的正确性。经典的 bug 是缓存却不失效，把陈旧数据供应数分钟；更隐蔽的是在同一次写入中*既*失效*又*设置，这会产生竞态。

## 踩踏保护与热点键

- **踩踏（惊群，thundering herd）：**当一个热点键过期时，成千上万个并发未命中会同时冲击 DB 并可能把它打垮。用**按键的锁/single-flight**（只有一个请求重新计算，其余等待）或在过期前的**提前/概率式刷新**来修复。
- **热点键：**一个键（一位名人的资料）可能让单个 Redis 节点的 CPU/网络饱和。分散它——把该键复制到多个节点上，或为最热的条目在 Redis 前面加一个小的本地进程内缓存。

## 面试视角

面试官希望看到你的思考超越"加个 Redis"。好：带 TTL 的 cache-aside。出色：你指出**踩踏保护、失效策略、热点键处理，以及缓存宕机时会发生什么**。陷阱是假设缓存永远在线——如果 Redis 死掉，每次未命中都穿透到 DB，你就会遭遇一场把 DB 也一并拖垮的**缓存雪崩（cache-avalanche）**。

## 权衡与故障模式

- **陈旧与负载：**短 TTL = 新鲜但更多未命中；长 TTL = 更少未命中但更陈旧。按数据调优。
- **缓存雪崩：**许多键同时过期（相同 TTL）会造成负载尖峰——给 TTL 加**抖动（jitter）**。
- **一致性：**缓存和 DB 可能分叉；对涉及金钱的关键读取，直接读 DB 或使用 write-through。
- **内存淘汰：**在压力下 Redis 会按策略（LRU/LFU）淘汰；错误的策略会悄悄丢弃你的热点集。

Cache-aside 与 read-through

TTL + 失效

踩踏保护与热点键

面试视角

权衡与故障模式

相关问题