缓存模式：谁来读写缓存，是一门学问

亿级规模系统系列 · 阶段 2 · 缓存体系 · 第 11/49 篇 · 🚧 占位待学
上一篇：《读写分离与主从复制：读扩展的第一刀》
下一篇：《缓存三兄弟：穿透、击穿、雪崩》
学习大纲：《QPS 过万与亿级消息系统设计学习总纲》

---

状态：待学习。 本文为占位文档：知识点清单、实验与验收标准已就绪，正文待按「先学习、先实验、再撰写」补全。
对应总纲单元：阶段 2 · 单元 2.3

一、本文要解决的问题

缓存这么快，为什么不全量走缓存、实时更新？因为「谁来维护缓存一致性」才是问题的核心。Cache-Aside 为什么成为工业界默认选择？缓存的 value 里到底该放什么？过期时间怎么定？每个决定都影响命中率与一致性。

二、知识点清单

• Cache-Aside（旁路缓存）：应用同时维护 DB 与缓存，读 miss 回填、写后删除——为什么它是默认选择
• Read-Through / Write-Through / Write-Behind：缓存层代理读写的三种模式，与 Cache-Aside 的对比
• 缓存对象设计：value 放 JSON 对象还是放 id 列表、大对象的拆分与组合
• 过期时间的艺术：热数据长过期 + 事件更新，冷数据短过期 + 兜底
• 缓存命中率：统计方法（hit/miss 计数）、多少算健康、命中率与 QPS 的换算

三、动手实验（学习时必须真跑）

• 给商品查询接口加 Cache-Aside（Spring Cache + Redis 注解版与手写版各一遍），压测前后 QPS 对比
• 给接口加命中率统计（Redis INCR 两个计数器），不同过期策略下对比命中率
• 故意在写路径「更新缓存而非删除」，观察并发写下脏数据如何产生（为下一篇埋线）

四、验收标准（全部通过才进入下一篇）

• 能解释为什么「先更新 DB 再删缓存」优于「更新缓存」
• 能给一个具体接口设计缓存对象与过期策略并说明理由
• 能量化说出自己接口的缓存收益（命中率 ×（DB RT − Redis RT））

五、写作提示（补正文时遵守）

• 开篇问题驱动；结构走「是什么 → 为什么 → 怎么做 → 背景知识」
• 所有代码、命令、输出必须先在本机跑通再写入，不得杜撰
• 版本口径以总纲环境清单为准（Spring Boot 3.x / MySQL 8.0 / Redis 8.x / RocketMQ 5.3.x / Kafka 4.3 / ShardingSphere 5.5.3）
• 涉及版本敏感结论时标注出处与时间

---

本篇完成后，把文首导航块的「🚧 占位待学」去掉，并在总纲处打卡。