重庆服务器托管：多层缓存返回不同版本时怎样定位一致性问题
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /da7be4c3fd23.html
📄
重庆服务器托管：多层缓存返回不同版本时怎样定位一致性问题
先做一次同请求对比：用同一个 URL、同一组请求头、同一出口 IP，连续请求多次，把每次响应的 Age、ETag、Last-Modified、X-Cache 一类头部原样记下来。如果同一个资源在短时间内出现两组以上不同的头部组合，就说明至少有一层缓存保存了不同版本，接下来要做的不是清缓存，而是判断哪一层在返回旧内容、旧内容是否还有保留价值。
先分清三种不一致，再决定查哪一层
多层缓存下“版本不同”通常不是一种问题，而是三种，处理路径完全不同。
- 同一层内新旧并存：同一台缓存节点上，部分请求命中旧对象、部分命中新对象。常见原因是刷新操作只作用于部分节点，或缓存键里混入了会变化的维度。
- 层与层之间版本错位：边缘层已经拿到新版本，中间层或源站前置缓存仍在提供旧版本。表现是同一次访问链路里，前半段头部显示新，后半段显示旧。
- 源站本身就返回两个版本：缓存只是如实放大了源站的不一致，比如多台源站应用未同时发布，或对象存储里同时存在两个同名文件。
区分方法是绕过缓存直连源站请求同一 URL，对比源站响应与缓存响应。若源站自身就不一致，先修发布流程，清缓存只能短暂掩盖问题。若源站一致而缓存层分裂，才进入缓存层排查。
用可区分证据锁定是哪一层在返回旧版本
不要靠“清一遍就好了”来判断，那只能证明问题会复现。更可靠的做法是给每层加可观测标记，并构造一个能区分层的对照请求。
- 在源站响应里写入一个随发布变化的版本标识，例如按发布批次生成的短串，写入自定义响应头。
- 在每一层缓存配置里保留或追加自己的命中标识，让最终响应能看出经过了哪些层。
- 用带随机查询参数的请求和不带参数的请求各发一次，观察两者是否命中同一份缓存对象。
- 固定一个出口 IP 连续请求，再换一个出口 IP 重复，比较结果是否随出口变化。
如果结果随出口 IP 变化，通常指向边缘节点分布或按地域分片的缓存；如果随查询参数变化，指向缓存键设计；如果只随时间变化、过一段时间自行一致，则更可能是刷新传播延迟，而不是配置错误。
保留、改写还是退出：三种取舍的适用前提
定位到具体层之后，真正的决策是旧版本相关内容怎么处理，而不是一律删除。
适合保留的前提：旧版本仍被外部依赖，例如旧客户端、旧合作方接口或历史页面仍在正常流量中。此时应保留旧版本，但把它隔离到独立缓存键或独立路径，并设置明确的过期时间，让它自然退出，而不是继续和新版本共用同一缓存键。
适合改写的前提：新旧版本差异只在局部字段，且旧内容仍有访问价值。做法是让缓存层对旧对象做一次内容替换或重定向到新版本，同时保留原 URL 可访问。改写要保证响应头与正文版本一致，否则会制造新的不一致。
适合退出的前提：旧版本已无外部依赖，且继续保留会持续污染缓存判断。退出时先停止写入旧版本，再让缓存自然过期，最后才考虑主动清理。直接清理而不切断旧版本写入，旧内容会再次被回填。
一个假设例子：某接口有两个版本 A 和 B，缓存键只按 URL 计算。若发布时先更新源站 B、再刷新缓存，刷新期间部分节点仍返回 A，就会出现同 URL 双版本。若把版本号纳入缓存键，A 和 B 各自独立缓存，不一致立刻消失，但代价是缓存命中率下降。是否值得，取决于两个版本并存的时间长短——并存时间短，隔离缓存键更划算；长期并存，则应优先推动旧版本退出。
验证处理是否生效，别只看请求量变化
处理完成后，用同一组对照请求重复前面的记录方法，确认同类请求返回的版本标识已经统一。这里要避免一个误判：请求量、抓取量或某个统计归零，并不能单独证明处理正确。它也可能来自流量自然波动、监控口径变化、请求被上游拦截，或缓存恰好整体过期。真正能说明问题的是同一请求在多次重复下返回一致版本，并且这种一致性能在预期的缓存周期内保持。
如果一致性能保持，下一步才是评估保留旧版本的缓存分区是否还需要继续存在；如果不能保持，说明还有一层未纳入观测，或者旧版本仍在被写入。此时应回到分层标记那一步，补上缺失层的标识，而不是反复清缓存。
另外两点容易混淆：robots.txt 的抓取限制不等于可靠的索引移除，缓存层的一致性和搜索引擎索引状态是两件事，不要用前者推断后者；站点地图也不保证收录。若旧版本涉及对外可见页面，缓存统一之后仍需单独核查索引层面的实际状态。
