一个响应头，就能把同一资源拆成几十份：Cloudflare 出手治理缓存抖动

一个响应头，就能把同一资源拆成几十份：Cloudflare 出手治理缓存抖动 — infoq.cn · 12 小时前 · ⚙️ 工程

CDN 缓存本应让同一份资源被大量用户共享命中，但现实是某些请求会携带高度发散的请求头，导致同一个 URL 在缓存里被拆成几十甚至上百个变体，缓存命中率随之崩塌，这类问题被称为缓存抖动（cache fragmentation）。Cloudflare 在博客中剖析了这一现象的成因：当服务器响应包含 Vary 头时，CDN 必须按 Vary 指定的请求头字段区分缓存键，一旦某些站点滥用 Vary，例如对 User-Agent、Cookie 或自定义头做区分，变体数量就会爆炸式增长，最终同一个对象在边缘节点占用大量存储却几乎不再被复用，甚至把真正热门的资源挤出缓存。除了命中率下降，碎片化还会推高回源流量、增加源站压力，并拉长部分用户的响应时间。Cloudflare 给出的治理思路分为几层：一是识别与度量，通过分析缓存键中变体分布的统计特征，找出变体数量异常多的对象；二是引入自动检测机制，在变体数量超过阈值时限制或合并，避免单个 URL 无限膨胀；三是对 Vary 的语义做更精细的处理，把实际影响响应内容的头和无关紧要的头区分开来，比如对常见 User-Agent 归一化分组而不是逐个字符串建缓存变体；四是向客户提供可见性与控制手段，让站点管理员能配置自己的 Vary 策略并观察命中率变化。作者的核心结论是：缓存抖动不是一个需要应用开发者自行解决的问题，而应当由 CDN 层面通过变体归一化、数量上限和可观测性工具系统性兜底，才能在保持 HTTP 缓存语义正确的前提下，让边缘缓存的容量与命中率回到健康水平。

核心信息

缓存抖动的根源在于 Vary 响应头与高度发散的请求头组合：CDN 为了保证语义正确，必须为每个不同的请求头值单独存储一个缓存变体，而 User-Agent、Cookie 等字段在实际流量中几乎每个用户都不一样，一个热门 URL 因此可能衍生出数十到上百个变体，边缘节点为这些低频变体付出的存储和回源成本远超其被复用的价值。
碎片化的代价不止命中率下滑：变体膨胀会挤占缓存容量，把原本可以全局命中的热点对象挤出边缘节点，迫使更多请求回源，源站带宽与延迟都会恶化；同时这些碎片变体大多只在个别用户身上出现一次，属于典型的负收益缓存条目，对整体用户体验是净损耗。
Cloudflare 的缓解方案强调分层治理：先通过统计手段识别变体数量异常的对象，再在变体超过阈值时进行限制或合并；同时对请求头做归一化处理，例如把成千上万种 User-Agent 字符串折叠成少量等价分组，从源头压缩变体空间，而不是简单粗暴地全部禁用 Vary，以免破坏依赖该头的站点逻辑。
治理的另一半是可观测性与控制权：Cloudflare 向客户提供变体数量、命中率变化等指标，并允许站点管理员自行配置 Vary 相关策略，使开发者既能利用 Vary 的正确语义做个性化响应，又不至于在毫不知情的情况下把缓存打散，形成平台兜底与用户自管相结合的机制。

💡 为什么值得读: 它把一个长期潜伏、绝大多数团队从未意识到自己中招的缓存性能黑洞讲透了，读完你会立刻想回去检查自己站点的 Vary 配置。

✍️ 小编看法: 这个问题最容易被忽略的地方在于：它几乎不会在开发或测试环境暴露出来。测试流量太小，变体根本起不来，一旦上线面对真实互联网的多样性——数以千计的 UA 字符串、每个用户各不相同的 Cookie——缓存键瞬间爆炸，而且性能是缓慢劣化的，没有任何告警会直接告诉你命中率的分母里混进了几百个僵尸变体。很多团队会误判为源站变慢或容量不足，方向完全走偏。更值得警惕的是行业惯性：前端和网关配置里大量存在的 Vary: User-Agent，很多是十年前为兼容老浏览器或移动端适配留下的历史包袱，如今浏览器能力已高度趋同，这些头带来的碎片化成本远大于其收益，却没有多少团队愿意回头清理。Cloudflare 把治理责任收到平台层，我认为这是对的方向，但也有代价值得观察：归一化本质上是平台替开发者做了一个判断——哪些请求头差异不影响响应内容——如果判断错误，用户会拿到本应个性化的响应，这类正确性风险必须谨慎控制在白名单范围内。另一个潜在张力是阈值限制的公平性：当某个 URL 触发变体合并时，谁受益谁受损并不对称，平台需要给受影响的站点足够透明的反馈。对普通开发者来说，下一步值得做的是自查自己域名下 Vary 的使用情况，把不必要的区分头清掉；对 CDN 行业而言，缓存键设计是否会因为这些治理手段重新标准化，值得关注。

🏷️ Cloudflare, caching, HTTP headers, CDN