收官，但不撤桌
从「接口 3 秒」一路写到热 key，这个系列主体内容齐了。收官这一篇不做知识复读——十六篇的细节都在各自的文章里，这里只做一件事：发一张作战地图。以后线上出了缓存相关的状况，先翻这张表，找到症状对应的篇目和第一动作，再决定要不要把整篇精读。
第一张地图：出事翻哪篇
| 症状 | 翻哪篇 | 第一动作 |
|---|---|---|
| 接口太慢，想上缓存 | 第 1 篇 | 先量耗时，再动手 |
| 选不好缓存模式 | 第 2 篇 | 默认 Cache Aside |
| key 越积越多、结构混乱 | 第 3 篇 | 定命名规范，拆大 key |
| 恶意请求查不存在的数据 | 第 4 篇 | 参数校验 + 空值缓存 |
| 某个 key 过期瞬间被打爆 | 第 5 篇 | 互斥锁或逻辑过期 |
| 大批 key 同时失效 | 第 6 篇 | 随机 TTL + 多级缓存 |
| 改了数据缓存没生效 | 第 7 篇 | 先改库，再删缓存 |
| 定时任务重复执行 | 第 8 篇 | SET NX EX + Redisson |
| 内存告警，key 不消失 | 第 9 篇 | 查淘汰策略与大 key |
| 重启后缓存冷启动雪崩 | 第 10 篇 | RDB + AOF 混合 |
| 读写分离后读到旧数据 | 第 11 篇 | 关键读走主库 |
| 主库挂了要人肉切换 | 第 12 篇 | 上哨兵，奇数节点 |
| 内存装不下了 | 第 13 篇 | Cluster 哈希槽分片 |
| 慢命令拖垮全站 | 第 14 篇 | scan 替代 + 慢日志排查 |
| 流量全砸在一个 key 上 | 第 15 篇 | 本地缓存 + key 打散 |
第二张地图：按生命周期读系列
如果把这系列当一本书读，顺序是精心排过的：
- 动工前（1-3）：量好耗时再缓存，选对模式，设计好 key 和容量——地基决定后面省多少心。
- 守住三大经典故障（4-6）：穿透、击穿、雪崩，面试和实战的双高峰。
- 写路径与并发（7-8）：一致性是缓存最日常的坑，分布式锁是最容易被简化出错的组件。
- 底层机制（9-10）：过期删除、内存淘汰、持久化——解释很多「玄学现象」的源头。
- 架构演进（11-13）：主从复制 → 哨兵 → 集群，三步走完高可用与容量扩展。
- 性能与热点（14-15）：单线程模型的软肋与补丁，热 key 的组合拳。
贯穿全系列的三条心法
一、缓存不是真相源。真相永远在数据库里，Redis 里的任何东西都应该可以随时重建。空值缓存是防穿透（第 4 篇），「先改库再删缓存」是保一致（第 7 篇），限流降级是保命（第 6 篇）——三件事背后是同一句话：缓存丢了可以重建，数据丢了没法交代。
二、每个机制都标价。互斥锁有锁超时的坑（第 5 篇），逻辑过期有脏读，本地缓存有内存和一致窗口，LFU 淘汰有计数开销，异步删除有释放窗口（第 9 篇）。技术选型不是挑「最好的方案」，是挑「付得起的代价」。
三、重要结论别让单点拍板。解锁要校验 requestId（第 8 篇），哨兵判死刑要多数派（第 12 篇），脑裂要写入限流兜底——单点的判断无论多聪明，都要给个否决机制。
最后一份礼物：上线检查清单
可以直接抄进团队的 Wiki：
- 所有 key 设过期时间（例外走白名单，第 3 篇）；
- 淘汰策略按业务定，缓存用途默认
allkeys-lfu（第 9 篇）； - 生产禁用 keys，批量读写用 Pipeline（第 14 篇）；
- 慢日志阈值 10 毫秒常开，纳入巡检（第 14 篇）；
- 防穿透三件套就位：参数校验、空值缓存、布隆过滤器按需（第 4 篇）；
- 大 key 定期扫描，热点接口有本地缓存预案（第 3、15 篇）；
- 一致性统一「先改库再删缓存」，读写分离场景补延迟双删（第 7 篇）；
- 持久化用 4.0+ 混合模式，重启演练进季度计划（第 10 篇）；
- 关键读走主库，主从 lag 进监控大盘（第 11 篇）；
- 内存水位 70% 告警，容量按增长速率提前扩（第 13 篇）。
十六篇，一次接口优化引发的搬家记，到这里就写完了。评论区常聊到「下一个系列写什么」——候选名单里有 MySQL 索引与事务、消息队列、分布式 ID，想看哪个，或者有别的题目，评论区说一声。
这个系列就到这。咖啡馆的灯还亮着，欢迎常来。
评论 (0)