缓存设计：系统设计面试通关指南

可视化演示

演示LRU缓存淘汰策略：访问数据移至头部（MRU端），缓存满时淘汰尾部（LRU端），实时展示命中率变化。

缓存基本原理

大厨每次做菜前，都会下意识扫一眼台面的调料盒：花椒还有吗？干辣椒够不够？如果台面上就有，直接抓一把下锅，整个过程不到一秒——这就是「缓存命中」。如果台面上没有，他得转身打开冷藏库翻找，来回少说也要半分钟——这就是「缓存未命中」。所谓缓存（Cache），本质就是给数据建一个「离手边更近的副本」：冷藏库（数据库）里的数据是权威版本，台面（缓存）上放的是高频访问的临时版本。

厨师伸手的频率并不均匀：有的菜一天被点十几次，有的菜一周都无人问津。台面空间有限，只能放最常被点的那些。衡量这个「放得准不准」的指标，就是命中率（Hit Rate）——命中次数占总访问次数的比例。

有了命中率，就能算出平均每次访问的耗时：命中时走缓存（几毫秒），未命中时走数据库（几十毫秒），两者按概率加权平均。

回到厨房：大厨的目标不是把冷藏库搬到台面，而是让台面上的每一寸空间都「放得恰到好处」。缓存设计的第一步，就是找到那盘最常被点的菜——数据访问的局部性，是缓存一切优点的来源。

架构模式

同样是备料，不同规模的厨房做法截然不同：街边小馆的大厨自己跑腿，星级酒店的厨房有专门的备料助手，连锁餐厅则有一套严格的备料与盘库流程。缓存架构模式，就是这几种「备料分工」的不同设计。

Cache-Aside（旁路缓存）是最常见也最灵活的模式，相当于「大厨亲自跑腿」：应用先查缓存，命中直接返回；未命中则查数据库，然后将结果回填缓存，最后返回给客户端。它的优势是应用对缓存行为有完全的控制权，任何缓存组件都能用。Read-Through（读穿透）则像「雇了一个助手」：应用只需要跟缓存代理要数据，代理自己查缓存、自己查数据库、自己回填，应用完全不需要关心缓存逻辑。Write-Through（写穿透）像「边炒菜边记账」：每次写数据库的同时立刻更新缓存，保证缓存与数据库几乎同步。Write-Back（写回）则像「打烊统一对账」：先写在台面上的便签（缓存），后台异步批量更新冷藏库台账（数据库），写入效率最高。

写入延迟的对比，可以用两个极简的表达式来概括：

选哪种模式，取决于业务要「快」还是要「稳」。秒杀场景要极致的写速度，选 Write-Back；账务系统要每笔都确认落库，选 Write-Through。就像大厨的备料方式取决于餐厅定位——路边摊讲究快，米其林讲究稳，各有各的取舍。

淘汰策略

台面空间只有那么大，新调料放上来之前，必须请走一位「老住户」。请谁走？这就是淘汰策略（Eviction Policy）要回答的问题。

FIFO（先进先出）最简单：谁先上台面，谁先回冷藏库，像排队打饭一样公平，但它不管使用频率——一盒刚开封却没人用的调料，可能先挤掉天天用的老干妈。LRU（最近最少使用）更聪明：最久没被碰过的调料被请走。像大厨心里有本账——昨天用过、上周用过、上月用过，优先淘汰最久没上过手的那盒。LFU（最不经常使用）按使用次数淘汰：用得最少的调料先走。它适合访问频率差异大的场景，但实现更复杂、还需要维护计数。TTL（过期时间）不是一种淘汰策略，而是每盒调料的「保质期」：不管用不用，到时间就要扔掉，防止食材变质。

在请求均匀分布的假设下，缓存容量 C 与数据总量 N 的比值直接决定了命中率上限：

实际工程中，面试官最爱让候选人手写 LRU。实现方案是「双向链表 + 哈希表」：双向链表维护使用顺序，哈希表提供 O(1) 的定位能力。每次访问一个 key，就把它摘下来挂到链表头部；容量满了，就把链表尾结点淘汰掉。这就像大厨给每盒调料贴了一张「最近使用时间」标签，同时又在脑海里维护了一张「调料位置索引」——拿哪盒、放回哪个位置，都是一瞬间的事。

一致性挑战

台面上的调料是冷藏库食材的「复印件」。客人点了一份回锅肉，大厨照着台面上的豆瓣酱做了——但如果冷藏库里的库存已经更新（换了新品牌），台面上还是旧标签，这盘菜的味道就对不上。这就是缓存与数据库的「一致性」问题。

双写（同时更新缓存和数据库）时，顺序至关重要。先删缓存再更新数据库是大部分人容易踩的坑：请求 A 删掉缓存后，还没来得及更新数据库，请求 B 发现缓存为空，去数据库读到旧值并回填缓存；等 A 写完数据库，缓存里躺着的还是 B 填的旧值——不一致的窗口被无限拉长。所以行业共识是先更新数据库，再删除缓存：即使删除缓存失败，最多也就是多查一次库，数据最终还是对的。

为了进一步压缩主从复制延迟造成的回填窗口，还有一招「延迟双删」：先删一次缓存，更新数据库，等一段时间（必须大于主从复制延迟），再删一次缓存。这个等待时间可以形式化为：

一致性是个光谱：强一致代价极高，最终一致在绝大多数业务里足够。大厨不需要每秒钟都核对台面与冷藏库的标签是否一字不差，只要保证「客人点菜的当下不出错、标签在可接受的时间内换新」，厨房就能有条不紊地运转。

三座大山

面试官最爱的「压轴题」，是缓存系统的三大经典故障，被戏称为「三座大山」。用厨房场景来记，一目了然。

缓存穿透：客人点了一道菜谱上根本不存在的菜（比如「火山岩浆炖乌龟」）。大厨每次都得去冷藏库翻找，翻遍整个库也找不到，白白耗费体力。恶意攻击者经常用大量不存在的 ID 来打接口，每个请求都直击数据库。解法有两个：一是「空值缓存」——连不存在也缓存一个空标记，下次直接挡住；二是「布隆过滤器」——在菜谱入口挂一张「可能的菜名清单」，清单上没有的直接拒绝，省得跑冷藏库。

缓存击穿：某道招牌菜（热点 key）的食材在前一秒刚好用完（缓存过期），下一秒所有客人都点了这道菜，大厨一个人冲去冷藏库取料，其他人只能在灶台前干瞪眼。它与穿透的本质区别是：这道菜是存在的，只是恰好缓存失效。解法是「互斥锁」——只让一个请求去冷藏库取料，其他请求耐心等待；或者给热点 key 设置「永不过期」，用后台线程定期续一下「保质期」。

缓存雪崩：更可怕的是所有调料盒同时空了——大量 key 在同一时间过期。所有客人的菜都要临时去冷藏库取，冷藏库的门被挤爆（数据库连接池耗尽）。解法核心是「错峰」：把过期时间打散，加上随机抖动，让雪崩变成细小的毛毛雨；再加上多级缓存（本地缓存 + 分布式缓存）作为第二道防线。

三座大山的数据库压力可以用一条公式直观对比：

记住这个「体检口诀」：穿透查「不存在」，击穿查「一个热点」，雪崩挂「一片热点」。能用一句话说清三者差异，面试基本上就成功了一半。

容量与优化

台面到底该做多大？这是缓存设计的收尾问题。台面太小，调料老是不够用，厨师频繁跑冷藏库；台面太大，成本高且占厨房空间。工程上有一个快速估算公式：

容量之外，还有几招优化手段：热点优化——个别招牌菜（如明星账号、爆款商品）单独建「小灶」，用独立缓存或者本地缓存扛住超高并发；监控手段——给厨房装「仪表盘」，紧盯命中率、缓存大小、淘汰数量、慢查询四项指标，命中率突然跳水意味着缓存策略可能出了问题；性能调优——对大 value 做压缩（调料盒换成真空包装）、选用更快的序列化方案、在分布式缓存前面再加一层进程内本地缓存，多级缓存层层兜底。

大厨最终的台面设计，不是一次定死的：他会观察一周的点菜记录，调整调料品种与数量，在不同时段动态微调。缓存设计也是一样——容量规划是起点，持续监控与调优才是让系统保持「顺手状态」的日常功课。

AI 应用场景

Python 演示

"""带 TTL 的 LRU 缓存：演示命中率统计与缓存穿透防护。"""import timefrom collections import OrderedDict  class TTLCache:    def __init__(self, capacity=3, default_ttl=5):        self.capacity = capacity        self.default_ttl = default_ttl        self._data = OrderedDict()          # key -> (value, expire_at)        self.hit_count = 0        self.miss_count = 0     def get(self, key):        if key not in self._data:            self.miss_count += 1            return None        value, expire_at = self._data[key]        if expire_at is not None and time.time() > expire_at:            del self._data[key]            self.miss_count += 1            return None        self._data.move_to_end(key)         # LRU: 标记最近使用        self.hit_count += 1        return value     def set(self, key, value, ttl=None):        ttl = self.default_ttl if ttl is None else ttl        expire_at = time.time() + ttl if ttl > 0 else None        if key in self._data:            del self._data[key]        self._data[key] = (value, expire_at)        if len(self._data) > self.capacity:            self._data.popitem(last=False)  # 淘汰最久未使用的 key     @property    def hit_rate(self):        total = self.hit_count + self.miss_count        return self.hit_count / total if total else 0.0  def load_from_db(key):    time.sleep(0.05)    return "data-" + key  def get_data(cache, key, enable_null_cache=False):    value = cache.get(key)    if value is not None:        return value    if key.startswith("ghost"):            # 模拟数据库中不存在的数据        if enable_null_cache:            cache.set(key, "", ttl=2)      # 空值缓存: 挡住穿透请求        return None    value = load_from_db(key)    cache.set(key, value)    return value  def main():    cache = TTLCache(capacity=3, default_ttl=3)    get_data(cache, "user:1")    get_data(cache, "user:1")    get_data(cache, "user:2")    for i in range(8):        get_data(cache, "ghost:%d" % i)    print("无防护: 命中率=%.2f%% (hit=%d miss=%d)" %          (cache.hit_rate * 100, cache.hit_count, cache.miss_count))     cache2 = TTLCache(capacity=3, default_ttl=3)    get_data(cache2, "user:1")    for i in range(8):        get_data(cache2, "ghost:%d" % i, enable_null_cache=True)    get_data(cache2, "ghost:0")    print("空值缓存: 命中率=%.2f%% (hit=%d miss=%d)" %          (cache2.hit_rate * 100, cache2.hit_count, cache2.miss_count))  if __name__ == "__main__":    main()

1. self._data = OrderedDict()用有序字典同时实现「双向链表」与「哈希表」，既能 O(1) 定位 key，又能记录插入顺序供 LRU 淘汰。
2. expire_at = time.time() + ttl if ttl > 0 else None每条数据记录过期时间戳，ttl=0 表示永不过期。
3. self._data.move_to_end(key)LRU 核心操作：每次命中把 key 移到末尾，相当于「放到台面最顺手的位置」。
4. if len(self._data) > self.capacity: self._data.popitem(last=False)容量满时把最开头的键淘汰，对应台面最久没被翻动的那盒调料。
5. if key.startswith("ghost")模拟数据库中不存在的数据，制造缓存穿透场景。
6. cache.set(key, "", ttl=2)空值缓存：把「不存在」也缓存 2 秒，挡住后续穿透请求。

常见误区

面试题