值班时收到缓存穿透告警，不少运维同事会先怀疑是不是流量突增，或者缓存节点本身出了状况。但缓存穿透和普通的流量起伏有一个很明显的分界：请求总量也许并不夸张，数据库那边的压力却在一直往上走。如果只盯着请求数看，很容易把它归到正常热点访问里，等数据库响应开始变慢，才意识到前面判断偏了。面对这种告警，第一步不是急着封禁，而是把访问特征拆开看清楚。
先分辨请求的分布形态
正常的热点访问，一般会集中在少数几个键上，比如某个活动页或某件商品的详情。缓存命中率往往先降后升，因为热点数据被重新加载后就能继续服务。异常扫描则不同，它表现为大量不同的键被依次请求，每个键只出现一两次，缓存几乎找不到命中机会。还有一类是参数构造，键名看起来正常，但参数值被反复替换，缓存层始终对不上号。这三种情况的处理方式差别很大，判断错了，后面的动作就容易跑偏。
几个可以快速观察的切入点
在同一个时间窗口里，如果请求的键名高度重复，更偏向热点访问；如果键名分散且数量远超日常水平，更偏向扫描；如果键名结构相似、参数部分却不断变化，更偏向参数构造。再看请求来源，正常用户访问通常带有合理的会话和来源分布，扫描行为往往来源集中，或者呈现规律性间隔。这些特征不需要复杂工具，值班时用日志抽样就能大致区分。
检查缓存键设计和空值处理策略
缓存穿透之所以反复出现，常见原因是查询不到数据时没有写入空值或短时占位标记，同一个不存在的键每次都被放行到数据库。另一种情况是键的生成规则过于宽松，外部传入的参数没有归一化就直接拼进缓存键，攻击者或爬虫只要改变参数顺序或大小写，就能绕过已有缓存。检查时重点看三处：不存在的键是否被缓存、空值缓存的过期时间是否合理、键的拼接是否做了必要约束。
临时处置和长期加固要有先后
收到告警后，先做限流和来源标记，对确认异常的请求做短时拦截，同时保留日志用于后续分析。不要直接封禁整个网段或全部来源，否则可能误伤正常用户和搜索引擎抓取。临时措施生效后，再回到缓存层做加固，包括补充空值缓存、调整键的归一化规则、对高频不存在的键增加短时黑名单。长期来看，还需要在应用层增加参数校验，避免外部输入直接决定缓存键的形态。
一份便于交接的排查清单
第一步记录告警时间和持续时长；第二步抽样请求日志并归类访问特征；第三步检查缓存命中率和数据库查询量是否同步上升；第四步确认空值缓存和键生成规则是否存在缺口；第五步记录临时处置动作和生效时间；第六步标注需要后续加固的条目。清单不用复杂，但每一步都要留下可核对的信息，这样下一班人员接手时不用从头猜测。
it数运在网站维护和技术支持中一直强调把问题说明白、把过程做清楚。缓存穿透告警本身并不可怕，怕的是把它当成普通流量波动处理。先把访问特征分清楚，再决定是限流、补缓存还是改键规则，顺序对了，处置才不会伤到正常访问。
