缓存设计避坑指南：从穿透击穿雪崩到容量监控

前阵子排查线上问题，接口延迟从 200ms 一路飙到 3.7 秒，数据库连接池被打满，页面大面积超时。最后查下来，不是 SQL 写得差，也不是机器不够，而是一次发布顺手改掉了缓存 key 的版本号，所有热点缓存一夜之间集体失效，流量在凌晨两三点直接灌进数据库。

这种场面你应该不陌生：缓存加了，数据库照样被打穿；缓存没挂，数据却经常对不上；缓存集群很稳，内存成本却高得吓人。这些都是缓存设计里最常见的问题，但很少有人系统地把它们讲清楚。这篇文章我准备从缓存类型选择、key 设计、更新顺序、穿透击穿雪崩的防御，再到容量估算和监控，完整梳理一遍我这些年在这个领域踩过的坑和沉淀下来的做法。

无论你是刚把 Redis 接入项目的新手，还是维护过一整套缓存方案的开发者，都能找到对得上号的场景。我把话放在前面：缓存这东西，难点永远不在“怎么读怎么写”，而在“什么时候失效、谁更新、多旧的数据能接受”。把这几个问题想明白了，缓存才算真正用起来了。

1. 缓存选型：数据是“热”还是“烫”决定了本地缓存还是集中缓存

很多人一提到加缓存，第一反应就是上 Redis。这没有错，Redis 确实是最通用的选择，但它不是所有场景的最优解。我见过不少架构，明明数据是单机上的配置字典，为了一点“缓存的意思”硬是引入了一整套 Redis 集群，结果网络延迟、运维成本、故障恢复全都要背在身上。

1.1 本地缓存与集中式缓存的分界线

先摆一张我常用的对比表，这里面有几个关键维度，选型的时候跑一遍就能得出结论。

这个表的第一行最关键。如果你的数据是“这台机器上独有”的，比如本地配置文件、模板片段、算法模型参数，那用本地缓存是天经地义的事情。它和省一次网络时间有关，但更重要的是它压根不需要别人来同步。如果是多实例共享的数据，比如商品详情、用户画像、订单状态，那必须走集中式缓存，否则每个实例各存一份，数据很快就会对不上。

我自己见过一个比较典型的翻车案例：某团队把用户标签缓存做成了本地缓存，每台机器启动时去数据库拉一次全量标签。上线初期只有两台实例，看不出问题；后来扩容到八台，运营修改了某个标签的分值，结果有的实例还是旧值，有的实例已经拉到新数据，同一个用户在不同请求下看到的标签居然不一样。这就是典型的“选错了缓存层级”。

1.2 用两个维度选型：读频率与更新容忍度

抛开上面的极端情况，绝大多数业务数据选缓存，只需要回答两个问题：

第一个问题：这个数据的读频率到底有多高？一个接口每秒被请求几千次，和一天总共被请求几百次，方案完全不同。读得越频繁，缓存带来的收益越明显，也越值得投入复杂度。

第二个问题：数据更新之后，系统能容忍多久的延迟？这里要区分两件事：多久能感知到数据变了，以及多久必须让用户看到新数据。有些数据晚几秒没问题，比如排行榜、推荐位；有些数据晚几秒就是线上事故，比如订单状态、支付结果。

按照这两个维度，我一般的判断逻辑是这样的：读频率高且允许短时间不一致的数据，优先上集中式缓存；读频率高但要求强一致的数据，缓存只能做加速手段，不能做数据权威来源，核心查询必须回源数据库；读频率低但修改频繁的数据，压根不要缓存，直接查库更省事。

这里还有一个我强烈建议的组合策略：本地缓存和集中式缓存不是二选一，而是可以串成一条链路。先查本地缓存，命中就返回；没命中再查 Redis； Redis 也没有才查数据库，然后逐层回填。这样做的好处是，Redis 挂了本地缓存还能挡住一部分流量，不至于一次缓存抖动就拖垮数据库。当然，本地缓存只适合放那些“能接受轻微不一致”的数据，不能把订单状态这类东西也塞进去。

2. key 设计：从一次串数据事故开始，把缓存键从“能跑”改到“不踩坑”

缓存 key 是全网最容易被忽视的东西。很多人觉得 key 嘛，随便拼个字符串能查得到就行。但真实线上环境里，key 设计不合理导致的串数据、数据陈旧、命中率低下，排查起来往往比业务 bug 痛苦十倍。

2.1 一次典型的 key 串数据事故复盘

先讲一个我印象很深的事故。当时做的是用户标签服务，最初只服务一个应用，缓存 key 设计成user:tag:{userId}，里面存的是该用户的标签 ID 列表。后来平台要复用这套服务，第二个应用也接了过来，同样传 userId 过去。

问题很快就来了：新应用的用户体系和第一个应用是两套，用户的 userId 编号完全可能重叠。A 应用的用户 10086 是个金牌用户， B 应用的用户 10086 是个新注册的普通号。两个应用共享同一个缓存 keyuser:tag:10086，结果 B 应用的用户拉回了 A 应用的标签，运营配置的专享活动直接给错了人。

这类串数据事故的特征非常明显：不是每次必现，而是只有两个系统的 userId 撞车时才出现，极其隐蔽。当时排查的时候，我们一度以为是接口传参错了，后来看了 Redis 里的 key 才发现，同一个 key 被两个业务方共用，写入方互相覆盖。

2.2 key 的组装规则：业务域、版本、唯一标识

那次事故之后，我强制团队统一了 key 的组装规范。到现在，我每写一个缓存 key，都会按照下面的格式来：

[业务域]:[场景]:[版本号]:[唯一标识]:[可选维度]

举几个实际例子：

• mall:goods:detail:v2:1001—— 商品详情
• trade:order:status:v1:20240301001:user_10086—— 订单状态（带用户维度）
• promo:activity:config:v3:618—— 促销活动配置

这几段的作用分别是：

业务域和场景，解决的是“这个 key 属于哪个功能”的问题。即使两个功能存的是同一个对象，也不要共用同一个 key，否则一个改了 key 结构另一个就被牵连。

版本号，解决的是“数据结构升级”的问题。只要缓存里存的数据结构变了，比如原来存字符串，后来改存 JSON，版本号就要加一。这样新老数据自然隔离，旧数据等 TTL 过期清掉就行，不会出现新代码读到老结构然后反序列化失败的问题。

唯一标识，很好理解，但要注意不只是主键那么简单。如果一个数据存在多个业务维度，要把所有影响读写的维度都拼进去。我见过不少 key 只拼了一个 userId，结果漏掉了 appId、cityId、channelId，最后数据互相污染。这类问题只能靠“写之前先罗列查询维度”来避免。

可选维度那段，是给同一个缓存对象的不同视角留的位置。比如商品详情，可能按用户等级展示不同价格，那 key 里就得加一个level字段，不然不同等级的用户会互相读到对方的专属价。

还要提醒一点：别把 key 设计得太长。一个几千字节的 key 不仅浪费内存，还会拖慢 Redis 的查找速度。上面这套规则拼出来的 key 一般控制在几十到一百字节以内，完全够用。如果某个数据天然就需要很长的标识，可以考虑对标识部分做哈希，但要注意可读性下降后，排查问题会比较麻烦。

3. 更新顺序：四个缓存写策略的真实代价与脏数据窗口

选好了缓存类型和 key 规则，真正的麻烦才刚刚开始。缓存的数据从哪来、更新的时候先动哪边，这几个问题几乎每天都会遇到。业界总结出来的缓存写策略，主流的就四种，但每一种都不是免费的。

3.1 Cache-Aside 写后删和删后写到底差在哪

先看最常用的 Cache-Aside。读流程很清晰：先读缓存，命中直接返回；没命中就查数据库，再把结果写回缓存。这个流程基本不会出大问题，真正容易踩坑的是写流程：到底是“先更新数据库再删缓存”，还是“先删缓存再更新数据库”？

我见过不少人凭直觉选了先删缓存再更新数据库，理由是“先把旧缓存干掉，数据库慢慢更新，总不会读到脏数据了吧”。但这个流程在并发下会出现一个非常恶心的窗口：

线程 A 要更新商品价格，它先删掉了缓存；线程 B 正好在读价格，缓存 miss 后去数据库查到一条旧价格，然后回填缓存；线程 A 这时候才把新价格写入数据库。结果就是：数据库里的价格已经更新了，缓存里的旧价格却被 B 线程重新放了回去，而且这个旧价格要一直待到 TTL 过期，期间所有用户看到的都是错的价格。

后删缓存的流程（先更新 DB 再删缓存）也会有一个短暂的不一致窗口：更新完数据库之后，删除缓存之前，如果来了一个读请求，它命中的还是那个旧缓存，读到旧数据。但这个窗口非常小，而且等删除缓存执行完，数据就恢复了，不会长期脏下去。所以两害相权，大多数团队最终都会选择“先更新数据库，再删除缓存”。

3.2 延迟双删与异步删除：什么时候值得加

每次讲到这里都会有人问：那先更新 DB 再删缓存，中间那几十毫秒读到旧数据就不算事故吗？

那要看业务容忍度。如果这个数据是商品库存、订单状态，用户多刷一次就能看到最新结果，那几十毫秒的窗口通常可以忽略。但如果是支付回调、对账数据，就必须尽量压缩这个窗口。

我实际用过的方案有两种。

第一种是延迟双删：先更新数据库，然后删除缓存；等几百毫秒之后，再删除一次缓存。上面那个“B 线程在删除前回填了旧缓存”的场景，第二次删除会把这份旧值清掉，把脏数据时间压到极短。这个 delay 时间怎么设？一般取一个略大于“慢查询 + 网络传输 + 回填缓存”的时间，500ms 到 1 秒对我来说够用。注意 delay 不是越长越好，越长时间段内系统越可能再次出现脏读。

第二种是异步删除：更新数据库后，把“删除这个缓存 key”的消息发给一个队列，由专门的消费者去删；删除失败会自动重试。这个方案适合删除缓存的操作经常因为网络抖动失败的情况。如果只是 delete 偶发失败，可以在业务代码里重试两三次；如果还担心失败，可以扫 Redis 的日志或者读数据库变更记录来补偿。

再往后进阶，是对强一致性要求极高的场景，有人会直接订阅数据库 binlog，在数据变更后异步清理对应缓存。这套方案比双删干净，因为它是从数据源头出发的，不依赖业务代码里删缓存是否执行成功。但复杂度也会明显上升，不是所有项目都需要。

最后总结一下我现在的默认选择：90% 的场景我直接用“先更新 DB，再删除缓存”；如果并发写很频繁且存在旧值回填风险，我会加延迟双删；如果删除失败可能性大，我会引入异步删除队列；极端高一致场景，才考虑订阅 binlog 做补偿。这个顺序从简单到复杂，每一步的引入都有明确信号，不会一上来就把架构搞得很重。

4. 穿透、击穿、雪崩：三道防线应该按什么顺序搭

说到缓存，一定会提到穿透、击穿、雪崩这三个词。很多人把它们混为一谈，但三个问题的本质完全不同，防御手段也完全不一样。我建议每个做缓存的人都把这三兄弟放在一起理解，因为它们极可能在同一个系统里同时出现。

穿透是指请求想查的数据在缓存和数据库里都不存在，于是一次次地穿过缓存，直接打到数据库。最典型的例子是用户疯狂请求一个不存在的商品 ID，每个请求都 miss，每个请求都查库，数据库的连接池很快就满了。

击穿是指某一个热点 key 过期瞬间，大量请求同时进入，全部 miss，一起打到数据库。这个和穿透的区别在于：穿透查的数据没有，击穿查的数据有，只是缓存刚好没了。

雪崩是指大量 key 同时过期，或者整个缓存集群不可用，导致大量请求在短时间内集中打到数据库，数据库直接被压垮。

4.1 穿透：空值缓存与布隆过滤器的边界

对付穿透，最直接的做法是：查数据库发现没有这个数据，也写一个空值进缓存，设置一个比较短的 TTL，比如 30 到 60 秒。这样同一个不存在的 key 再次被请求时，会直接命中空值缓存，不再穿透到数据库。这个方案简单有效，但有一个副作用：如果一个 key 本来不存在，后来在数据库中真的创建了，而空值缓存还没过期，那这期间它仍然是查不到的。所以空值缓存一定要设置短 TTL，不能图省事设成几小时。

另一种手段是布隆过滤器，在请求进来之前先判断这个 key 是不是一个可能存在的 key。布隆过滤器判断“不存在”是绝对准确的，判断“存在”则可能误判。所以它的定位是挡掉大部分不存在的请求，而不是替代空值缓存。我见过的常见做法是：把系统里所有合法 ID 都打进布隆过滤器，请求来了先过过滤器，如果判断不存在，直接返回；如果判断存在，才走正常的缓存查询流程，查不到再做空值缓存兜底。

这里有一个非常容易忽略的细节：布隆过滤器的容量和误判率是绑定的。一开始我把容量设得太小，数据量上来之后误判率越飙越高，大量其实不存在的 key 被放行到了数据库。后来我把容量预估为“未来两年预期数据量的十倍”，并且宁可多占一点内存，也要把误判率压到 1% 以下。上线之后才发现，配置一个合理的布隆过滤器，比事后给数据库加索引省心得多。

4.2 击穿：互斥重建与逻辑过期的两种路线

击穿的核心问题是热点 key 失效后，并发请求全部打到数据库。最直接的对策是互斥重建：同一时刻只允许一个线程去数据库查数据，其他线程等待这个线程把缓存写回去，然后再从缓存里读。

互斥重建的实现有很多种，Redis 分布式锁是其中一种。我贴一段常用的伪代码，完全可以直接抄进项目里试：

def rebuild_cache_with_lock(key, redis_client, build_func): data = redis_client.get(key) if data: return data lock_key = f"lock:{key}" # 抢锁成功才允许重建，ex为锁过期时间 if redis_client.set(lock_key, "1", nx=True, ex=30): try: # 二次检查，防止等待期间别人已经重建 data = redis_client.get(key) if data: return data data = build_func() redis_client.set(key, data, ex=300) return data finally: redis_client.delete(lock_key) else: # 抢不到锁的请求，等一下再读缓存 time.sleep(0.1) return redis_client.get(key)

互斥重建的问题在于：抢不到锁的那些请求都在等待，如果数据库查询很慢，等待时间会拉长，接口整体响应时间会变差。所以这个方案比较适合“缓存重建成本不高、热点明确、并发瞬间极高”的场景。

另一种思路是逻辑过期。缓存里的数据并不真的等到 TTL 过期才失效，而是业务层自己给数据加一个逻辑过期时间。比如商品详情，实际 TTL 设成一天，但 Value 里存一个 expireAt 字段写上 10 分钟。每次读的时候判断 expireAt 是否已过，没过就正常返回；过了就立刻返回当前缓存数据，同时异步触发一个后台任务去刷新缓存并更新 expireAt。

逻辑过期最大的优点是请求永远不会阻塞，用户即使拿到旧数据也是秒回；代价是数据不一致的时间窗口会比 TTL 更大，而且异步刷新如果没有做好防重，同样会造成数据库压力。我会把它用在那些“响应时间不可牺牲、数据可以短期不精确”的场景，比如首页推荐内容、运营配置的营销文案。

4.3 雪崩：随机过期时间只是最低要求

雪崩的经典原因是同一个时间点太多 key 一起过期。最基础的对策是给 TTL 加一个随机数，比如所有 key 原本是 600 秒过期，现在生成缓存时按600 + random(0, 300)来设置。这样做能让失效时间分散开，数据库不会被一个集中失效点打爆。

但随机过期时间只能预防“自己设计出来的雪崩”，防不住“缓存集群整体挂了”这种外部故障。后者需要的是更高一层的防御机制。我在实践中主要做三件事：

一是多级缓存。前面已经提到，本地缓存做第一层，Redis 做第二层，DB 做第三层。即使 Redis 整体不可用，本地缓存也能挡掉一部分热点流量。

二是服务降级。如果数据库压力已经快扛不住，直接把缓存读接口的返回值降级为一个简化的默认数据，或者返回上一次成功的数据。不要在雪崩发生时还去执着于“把数据取到最新”，先把系统保住。

三是熔断限流。当下游 DB 的响应变慢、错误率升高时，缓存服务要主动减少进入 DB 的请求数量，而不是让更多的请求继续涌入。限流可以直接在网关层做，也可以在每个服务的调用链路上做。

这三个机制一层一层叠上去，才能称得上“防雪崩”。单纯靠 Redis 加大内存，遇到集群故障同样无能为力。我自己的习惯是：先确保随机过期时间这个基础工作做到位，再逐步引入多级缓存和降级策略，不要反过来先做很复杂的模块，结果基础的随机 TTL 都没配。

5. 容量估算与监控：如何判断缓存是“真的在干活”还是“白占内存”

很多团队的缓存上线之后，就再也没有人看它一眼。只有线上出问题了才翻一下监控，平时命中率是多少、内存涨到多少、有没有大量淘汰，一概不管。这样做的后果是，缓存慢慢从“加速器”变成了“隐形炸弹”。

5.1 命中率是必要条件，但不是健康标准

最常见的监控指标是命中率。命中率当然是越高越好，一般业务缓存能到 90% 以上就算不错。但如果你只盯着命中率，很容易被骗。

举个例子，一个商品详情缓存，TTL 设成 30 分钟，白天高峰期命中率可以达到 95% 以上。但到了深夜，请求量下降，大量缓存因为 TTL 过期而清空，凌晨的活动预热流量一进来，全部 miss，命中率会瞬间跌到 50% 以下。这种命中率波动是正常的，不代表系统出了问题。

反过来也一样：命中率高不等于缓存健康。如果某个缓存 key 的命中率很高，但对应的数据几乎没人读，那不过是在白白占内存。所以除了命中率，我会额外看三个指标：缓存读延迟分布、数据库 QPS 走势、以及 Redis 的内存淘汰数量。

缓存读延迟和数据库 QPS 是最能反映“缓存有没有真正挡住数据库压力”的指标。如果缓存命中率很高，但数据库 QPS 仍然很高，那大概率是某些 key 没有走到缓存，或者查询绕过了统一缓存服务，这就要去查代码链路了。内存淘汰数量（evicted_keys）暴涨，说明内存容量不够，开始主动淘汰 key 了，这时候命中率可能不降，但淘汰掉的 key 会让后续请求重复回源数据库，DB 压力会悄悄上升。

5.2 一个可用的容量估算方法和压测准备

还没有上线的缓存，提前估算内存是很有必要的。否则等缓存上线后内存被撑爆再扩容，中间的抖动很难受。我这里提供一个非常实用的估算公式：

缓存所需内存 ≈ 活跃key数量 × (key长度 + value长度 + 平均额外开销)

这个“平均额外开销”包括 Redis 的对象头、字典节点、过期指针等，一般可以按 100 字节左右来估。举个例子：一个商品详情缓存，key 平均 30 字节，value 是一个 2KB 的 JSON，活跃 key 数量大概 100 万条，那么估算出来：

100万 × (30 + 2048 + 100) ≈ 2.18 GB

这个结果已经考虑了基本开销，压测之后如果发现实际占用偏差很大，再回来修正系数。记住一点：估算的是“活跃 key 数量”，不是“key 的总量”。很多业务里 key 的总量很大，但真正在有效期内被频繁读取的只有一小部分，所以按总量估算会严重偏大。

上线之后，我还建议做一件很多人没做的事：压测缓存节点。不是拿 Redis 自己提供的 benchmark 工具随便跑一下，而是用接近业务真实读写比例的流量去打。看两个数据：缓存节点在 QPS 达到预期的多少时开始出现延迟毛刺，以及内存使用率达到多少时开始触发淘汰。这两个数据是容量规划的底线，知道了底线，后续做扩容和限流才有的放矢。

6. 最后分享一个让缓存过期时间不乱掉的实践经验

刚才讲的都是技术方案，最后我想聊一个偏工程管理的小经验：过期时间千万不要散落在代码的各个角落里。

我见过太多项目，同一个商品详情缓存，有人写 10 分钟过期，有人写 30 分钟过期，还有人写 1 小时过期。业务上线的时候大家相安无事，一旦大促活动策划要求“商品修改后 5 分钟内生效”，你会发现代码里全是魔法数字，根本不知道从哪里改起。

我的做法是：把所有缓存 key 的 TTL 配置统一收敛到一个配置中心，按业务场景命名，并支持运行时调整。配置文件大概是这个样子：

cache: rules: goods-detail: 600 goods-sales-rank: 120 user-tag: 0

这里的规则名称对应代码里的缓存 key 前缀，TTL 单位是秒。user-tag: 0表示这个缓存不设置 TTL，完全由业务逻辑控制失效。把 TTL 做成可配置之后，最大的好处是：大促期间想临时把商品详情缓存调到 60 秒，不用发版，不用改代码，配置中心推送一下就生效了。

另外一个相关的小习惯是：每次发版涉及数据结构变化时，强制把对应的版本号加一，并且把旧 key 的清理动作纳入发布计划。很多缓存事故，回头看都是因为“升级了结构但忘了换 key 版本号”。把这些流程固定下来，虽然看起来没有解决某个具体的技术难点，但在我的实际经验里，它比任何一套复杂的缓存淘汰算法都更能避免线上故障。