当CDN突然失忆：我是如何揪出缓存未命中元凶的

上周四凌晨2点，我被刺耳的电话铃声惊醒。运维同事急促的声音传来：”我们的商品详情页突然全部回源了，CDN命中率从99%暴跌到40%！” 这就像你家的冰箱突然不制冷了，所有食物都得临时去菜市场现买——对于电商系统来说，这就是一场灾难。下面记录下这次惊心动魄的排查之旅。

第一反应：检查最明显的嫌疑犯

我揉着惺忪睡眼连上VPN，第一件事就是检查CDN控制台。像侦探勘查现场一样，我重点关注三个地方：

• 缓存规则是否被修改（特别是最近上线的灰度策略）
• 源站是否返回了异常的Cache-Control头
• 是否有异常的Purge操作记录

结果全都正常，这反而让事情更诡异了。正当我准备喝第三杯咖啡时，突然注意到监控图表上一个细微的波动…

发现关键线索：时间戳的阴谋

通过对比CDN日志和业务日志，我发现所有未命中的请求都有个共同特征：URL中都包含一个v=202307的参数。这个看似无害的版本号参数，实际上是埋了三个月的地雷：

// 问题代码示例
function generatePageUrl(productId) {
  const version = new Date().getFullYear() + ('0' + (new Date().getMonth()+1)).slice(-2);
  return `/products/${productId}?v=${version}`;
}

原来这是前端同事为了强制刷新静态资源加的”小聪明”，但没人注意到这个逻辑也被用在了API请求上！当时间从6月跳到7月，所有URL都变成了新版本，CDN自然认为这是全新的请求。

修复方案：外科手术式的缓存策略

我们最终采取了组合拳解决方案：

1. 对API请求移除动态版本号，改用ETag协商缓存
2. 对真正需要强刷的静态资源，改用内容哈希而非时间戳
3. 在CDN配置中添加忽略特定参数的规则

特别想分享下第三条的Nginx配置，这对类似场景特别有用：

proxy_cache_key $scheme$proxy_host$uri$is_args$args_without_v;
map $args $args_without_v {
  default "";
  "~(.*)(&v=[^&]+|v=[^&]+&?)(.*)" "$1$3";
}

事后复盘：那些血泪教训

这次事故教会我几个重要经验：

• 监控要带上下文：单纯看CDN命中率不够，需要关联URL模式变化
• 缓存标识要谨慎：时间戳是最危险的缓存破坏者之一
• 变更要有回滚计划：特别是涉及全局缓存策略的修改

现在每次看到URL里带时间戳的参数，我都会条件反射地虎躯一震。希望这篇记录能帮你避开这个坑，如果你的CDN也突然”失忆”，不妨先检查下URL里是否藏着这样的时间炸弹。