缓存设计模式（Cache-Aside / Read-Through / Write-Behind）

可视化演示

展示Cache-Aside的读命中/未命中流程与写失效流程，以及旁路/通读/通写/后写四种模式对比，滑杆调节缓存命中率。

缓存基础：给冰箱定个位

周末你想做番茄炒蛋，先打开冰箱：有鸡蛋就直接开工，没有就得跑一趟超市。这里的冰箱是缓存，超市是数据库。冰箱离你近、拿东西快，但空间有限；超市什么都有，可一来一回太费时间。高并发系统里的缓存，本质上就是这套“冰箱备菜术”。

数据库往往放在磁盘或远端，一次查询可能要几毫秒甚至几十毫秒；而 Redis 这类缓存放在内存里，一次读取只要亚毫秒。于是我们让热点数据住在“冰箱”里，把数据库从高频请求中解放出来。这里有几个关键概念：存储层级决定谁离 CPU 更近；命中代表冰箱里有菜；穿透则意味着冰箱没有，请求只能穿过缓存去数据库。

穿透过一次没什么，可怕的是大量请求同时发现“冰箱空空”，一起涌向超市，数据库会被瞬间打垮。因此，我们需要先记住一个最朴素的质量指标——缓存命中率。

缓存不是免费的：它占用内存、需要维护、还可能带来数据不一致。所以先把冰箱的定位想清楚，后面三种模式才有讨论的基础。

旁路读取：自己动手的 Cache-Aside

Cache-Aside 是三种模式里最像“自己动手做饭”的一种。读请求来了，应用先打开冰箱看：有菜就直接用；没有菜，就去超市买，回到家顺手把一份放进冰箱。整个过程由应用自己编排，缓存和数据库都被它直接操作。

写请求的规则要更讲究：先更新超市货架（数据库），然后把冰箱里对应的旧标签撕掉（删除缓存）。为什么不直接更新缓存？因为并发场景下，你刚把新值写进缓存，另一个线程可能正拿着旧值准备回填，晚到的旧值会把新值覆盖掉，冰箱里就成了过期货。直接删除缓存，让下一次读请求从数据库拉新值，反而更安全。

这套流程有一个很直观的平均延迟公式：

Cache-Aside 逻辑透明、容易控制，是大多数读多写少业务的首选。它像开手动挡汽车：司机需要知道什么时候换挡，但正因为“人在回路”，出了问题时最好排查。

穿透读取：会补货的智能冰箱

Read-Through 像是换了一台会自己补货的“智能冰箱”。应用只需要对冰箱说“我要鸡蛋”，冰箱发现没有，就会自己打电话给超市，把货运回来再交给你。应用不再关心数据库在哪里，也不用写“查库再回填”这套样板代码。

从架构上看，Read-Through 把缓存从“被动存储”变成了“主动代理”。缓存组件内部定义了自动回源逻辑，应用只面向缓存读写。这样做的最大好处是职责收口：所有缓存的加载策略、过期策略、回填逻辑都集中在一个地方，不会散落在几十个调用方里。

它的读取耗时可以写成：

Read-Through 特别适合团队希望“让数据库对上层透明”的场景。只要缓存模式定下来，调用方永远只问冰箱，省心省力。

延迟写入：先写清单再购物

Write-Behind 的思路更像“把想买的东西先记在购物清单上，周末再去超市一次性采购”。应用收到写请求后，不立刻写数据库，而是先更新缓存，再往待写清单里记一笔；后台服务按照批次把清单统一写回数据库。

这样做的第一个好处是批量合并：一千次对同一个 key 的修改，可能只落库一次，数据库压力成倍下降。第二个好处是削峰填谷：双十一零点瞬间涌入的订单，不会直接砸向数据库，而是先被清单“缓冲”住，再匀速写库。可以用一个简单公式描述批处理效果：

代价也很明显：如果“购物清单”还没送出，冰箱突然起火，这批数据就丢了。所以 Write-Behind 适合日志、计数、非核心状态这类允许短暂丢失或可补偿的数据，不适合银行转账这种一分钱都不能错的场景。

一致失效：别让缓存变馊

冰箱里的菜放久了会馊，缓存里的数据放久了也会和数据库不一致。想让缓存一直“新鲜”，不能只靠过期时间，还要主动治理。

最经典的手法叫“双删”：更新数据库后删除一次缓存，等一小段时间，再删除一次。为什么要删两次？因为数据库主从同步有延迟，第一次删除后，可能还有从库读到旧数据，并把旧数据写回缓存；第二次删除可以把这些刚刚回填的旧值再清掉。除此之外，我们还可以用消息队列异步通知删除、用 TTL 做最后兜底。这样系统追求的就不是强一致，而是可接受的最终一致。

所有一致性手段加在一起，可以给“不新鲜”画一条上限：

别指望“把 TTL 调小”就能解决一切。治理缓存一致性，更像是定期清理冰箱：主动扔掉过期食材，同时让保质期作为最后防线。

性能实战：把冰箱用到极致

冰箱不是塞得越满越好，而是刚好存下你最常吃的菜。性能优化的核心，就是让缓存存得“准”而不是“多”。

第一步是提升命中率：启动时把热点数据预加载进缓存，给不同 key 设置合理 TTL，避免把冷数据也塞进冰箱。第二步是保护“缓存击穿”：当一个热点 key 过期，瞬间涌入的大量请求会同时冲向数据库，这时可以用互斥锁让只有一个线程回源重建，其他线程等待结果。第三步是监控容量：容量规划不能靠拍脑袋，缓存大小、淘汰率、命中率都要持续观测，否则冰箱早晚会被塞爆。

容量规划可以用一个很朴素的公式估算：

性能优化没有银弹，无非是让命中率更高、击穿更少、容量更合理。冰箱用得好，高并发也能游刃有余；用得不好，再大的机器也扛不住洪峰。

AI 应用场景

Python 演示

class SmartFridge:    def __init__(self, fridge_db):        self.cache = {}        self.fridge_db = fridge_db        self.todo = {}     def get_cache_aside(self, key):        if key in self.cache:            return "hit", self.cache[key]        value = self.fridge_db[key]        self.cache[key] = value        return "miss", value     def get_read_through(self, key):        if key not in self.cache:            self.cache[key] = self.fridge_db[key]        return self.cache[key]     def write_behind(self, key, value):        self.todo[key] = value        self.cache[key] = value     def flush_todo(self):        count = 0        for key, value in self.todo.items():            self.fridge_db[key] = value            count += 1        self.todo.clear()        return count db = {"apple": 3, "milk": 1}fridge = SmartFridge(db)print(fridge.get_cache_aside("apple"))print(fridge.get_cache_aside("apple"))print(fridge.get_read_through("milk"))fridge.write_behind("egg", 12)print("flush", fridge.flush_todo())print(db)

1. def get_cache_aside(self, key):旁路读取的入口：先看冰箱，再看超市。
2. if key in self.cache:判断缓存是否命中，相当于打开冰箱门检查。
3. self.cache[key] = value未命中时把数据库结果回填缓存，买完菜放一份进冰箱。
4. def get_read_through(self, key):把“查库 + 回填”封装在缓存对象内部，调用方只面向缓存。
5. self.todo[key] = valueWrite-Behind 只更新缓存和待写清单，数据库暂时不动。
6. def flush_todo(self):模拟后台任务把待写清单批量落库，返回本次写了几条。

常见误区

面试题