# 网站维护中收到缓存穿透告警，运维先区分哪几类访问特征

- Link: https://www.itor.cn/345.html
- Published: 2026-09-28T18:56:12+08:00
- Author: it

值班时收到缓存穿透告警，不少运维同事会先怀疑是不是流量突增，或者缓存节点本身出了
状况。但缓存穿透和普通的流量起伏有一个很明显的分界：请求总量也许并不夸张，数据库
那边的压力却在一直往上走。如果只盯着请求数看，很容易把它归到正常热点访问里，等数据
库响应开始变慢，才意识到前面判断偏了。面对这种告警，第一步不是急着封禁，而是把访问
特征拆开看清楚。

先分辨请求的分布形态

正常的热点访问，一般会集中在少数几个键上，比如某个活动页或某件商品的详情。缓存命中率
往往先降后升，因为热点数据被重新加载后就能继续服务。异常扫描则不同，它表现为大量
不同的键被依次请求，每个键只出现一两次，缓存几乎找不到命中机会。还有一类是参数构造，
键名看起来正常，但参数值被反复替换，缓存层始终对不上号。这三种情况的处理方式差别
很大，判断错了，后面的动作就容易跑偏。

几个可以快速观察的切入点

在同一个时间窗口里，如果请求的键名高度重复，更偏向热点访问；如果键名分散且数量远
超日常水平，更偏向扫描；如果键名结构相似、参数部分却不断变化，更偏向参数构造。再看
请求来源，正常用户访问通常带有合理的会话和来源分布，扫描行为往往来源集中，或者呈现
规律性间隔。这些特征不需要复杂工具，值班时用日志抽样就能大致区分。

检查缓存键设计和空值处理策略

缓存穿透之所以反复出现，常见原因是查询不到数据时没有写入空值或短时占位标记，同一个
不存在的键每次都被放行到数据库。另一种情况是键的生成规则过于宽松，外部传入的参数
没有归一化就直接拼进缓存键，攻击者或爬虫只要改变参数顺序或大小写，就能绕过已有缓
存。检查时重点看三处：不存在的键是否被缓存、空值缓存的过期时间是否合理、键的拼接
是否做了必要约束。

临时处置和长期加固要有先后

收到告警后，先做限流和来源标记，对确认异常的请求做短时拦截，同时保留日志用于后续
分析。不要直接封禁整个网段或全部来源，否则可能误伤正常用户和搜索引擎抓取。临时措施
生效后，再回到缓存层做加固，包括补充空值缓存、调整键的归一化规则、对高频不存在的
键增加短时黑名单。长期来看，还需要在应用层增加参数校验，避免外部输入直接决定缓存
键的形态。

一份便于交接的排查清单

第一步记录告警时间和持续时长；第二步抽样请求日志并归类访问特征；第三步检查缓存命中率
和数据库查询量是否同步上升；第四步确认空值缓存和键生成规则是否存在缺口；第五步记录
临时处置动作和生效时间；第六步标注需要后续加固的条目。清单不用复杂，但每一步都要
留下可核对的信息，这样下一班人员接手时不用从头猜测。

it数运在网站维护和技术支持中一直强调把问题说明白、把过程做清楚。缓存穿透告警本身
并不可怕，怕的是把它当成普通流量波动处理。先把访问特征分清楚，再决定是限流、补缓
存还是改键规则，顺序对了，处置才不会伤到正常访问。