How we could save petabytes of cache storage with Zstandard and Pingora

我们如何通过 Zstandard 和 Pingora 节省数 PB 的缓存存储空间 | Cloudflare 博客

post

性能

Pingora

缓存

压缩

实习经验

2026年9月1日

我们如何通过 Zstandard 和 Pingora 节省数 PB 的缓存存储空间

Aashi Patel

8分钟阅读

复制链接

内存成本正在急剧上升。过去一年，RAM 和硬盘驱动器的价格都大幅上涨。在 Cloudflare，我们运行着多个大规模分布式存储产品（包括我们著名的 CDN），这些产品依赖于高效利用已部署的内存，以继续为所有客户提供服务。

基于这一考虑，我们原型设计了一种扩展有效缓存容量的方法。通过在 Pingora 中使用 Zstandard 对符合条件的资源进行编码，该架构以轻微的 CPU 增加换取显著的存储和跨数据中心带宽节省。

我们正在原型设计一个名为 Cache Transcoding 的系统，这是我作为 Cloudflare 1.1.1.1 实习计划实习生期间构建的。当符合条件的响应进入缓存时，我们会在将其写入磁盘之前使用 Zstandard（或 zstd）对其进行编码。在资源存在于缓存中并通过分层缓存在数据中心之间移动时，我们保持这种压缩形式，然后在向客户端提供响应之前对其进行解码。

在我们的初步测试中，这种编码将符合条件的资源平均缩小到原始磁盘大小的 1/3。在面向源的代理中，额外的 CPU 成本估计很小，但这就是权衡。CPU 的小幅增加为 Cloudflare 带来了数 PB 的有效缓存容量，并减少了数据中心之间的数据传输量。编码成本仅在资源进入缓存时支付一次。存储和带宽节省会在每次资源被重复使用时持续发生。

什么是 Zstandard？

Zstandard（或 zstd）是由 Facebook 的 Yann Collet 开发并于 2016 年开源的无损压缩算法。无损意味着在解码压缩数据后，每个字节都与原始数据完全相同。我们可以在不改变资源本身的情况下改变其在磁盘上的表示形式。

zstd 的设计平衡了压缩率与速度。在我们之前的浏览器压缩测试中，它比 Brotli 快 42% 地压缩数据，同时生成的文件大小几乎相同，并且在可比速度下生成的文件比 gzip 小 11.3%。这种平衡很重要，因为 Cache Transcoding 会处理大量流量，因此编码和解码都需要保持快速。

原型使用 zstd 级别 3，在不使缓存填充成为 CPU 瓶颈的情况下，为我们提供了大部分压缩优势。

Cloudflare 传统上使用其源提供的内容编码来存储资源。如果源发送未压缩的响应，我们会将这些未压缩的字节存储在磁盘上，并以相同形式在数据中心之间传输。Cache Transcoding 在缓存本身内部添加了压缩。

并非所有内容都值得压缩

转码并不意味着压缩所有内容。图片、视频和字体通常已经过压缩。在我们的流量样本中，这些媒体内容占请求的 21.4%，但占字节总量的 63.3%。再次压缩它们只会浪费 CPU 资源。

可压缩的文本则不同。HTML、JSON、CSS 和 JavaScript 占请求的 67.3%，但仅占字节总量的 22.3%。在这些文本内容中，约 71% 以未压缩形式到达，且 Content-Encoding 未设置，压缩效果良好。

在我们受控的测试语料库中，符合条件的资源压缩了约2.8倍。

| 指标 | 值 | |--------------|-----------------------------| | 压缩比 | 2.834倍 | | 编码成本 | 每字节4.31纳秒，约232 MB/s，每次填充仅计费一次 | | 解码成本 | 每字节1.56纳秒，约641 MB/s，每次提供服务均计费 |

虽然每字节的编码成本更高，但资源的提供频率远高于填充频率。通过改变资源的表示方式，现有硬件可以存储更多用户内容。

磁盘上的字节数减少意味着每台服务器可以保留更多对象。这提高了缓存密度，减少了因未压缩表示占用过多空间而导致有用内容被驱逐的可能性。

较小的表示形式在资源通过分级缓存时也有帮助，因为它减少了Cloudflare数据中心之间的数据传输量，使骨干网络使用更加高效。

一次性支付压缩成本

压缩从不免费。编码和解码都会消耗CPU，因此关键问题是字节节省是否值得处理成本。

在zstd级别3（通常是速度和压缩大小输出的默认平衡点），我们的模型在测试的流量和重用假设下，将额外的CPU成本控制在百分之几以内。

我们最初考虑仅对热门内容进行转码，因为热门资源的重用率更高，但这并没有帮助。解码发生在每次提供资源时，因此仅对最热门内容启用该功能会减少存储节省，但无法同比例降低CPU消耗。

更简单的策略效果更好。对所有符合条件的可压缩文本（4千字节（KiB）及以上）进行转码，几乎捕获了所有测量的存储收益，同时保持在CPU预算范围内。

缓存转码的工作原理

在缓存未命中时，基于Pingora的代理会使用zstd对正文进行编码，然后写入磁盘。缓存元数据记录存储的表示形式已压缩，并保留原始内容长度。在响应离开代理之前，正文会解码回原始标识表示形式。

在缓存命中时，从磁盘读取存储的zstd对象并进行解码。在分级缓存中，压缩表示形式以压缩形式从上层转移到下层。解码仅发生在面向客户端的跃点。

在完全缓存未命中时，上层从源站获取标识字节。这些字节会被编码一次，存储为zstd，并以压缩形式传输到下层。下层也会存储zstd表示形式，然后在请求路径上对其进行解码。

如果下层未命中但上层已有该对象，源站不会参与。压缩对象直接在缓存层级之间传输。它在传输过程中和磁盘上保持压缩状态，然后在下层仅解码一次。

如果下层已有该对象，则不需要网络传输或编码。下层从磁盘读取zstd字节，进行解码，然后将原始资源传递下去。

存储编码标记防止对象被多次编码。接收来自其他层级对象的缓存层级可以看到它已使用zstd存储，并保持该形式。

为什么我们只转码某些文本

最快的压缩操作是我们不需要执行的。因此，缓存转码使用一系列资格检查来避免对不太可能受益的内容进行处理。

原型仅在Content-Encoding未设置、Content-Type为可压缩文本且响应已知Content-Length至少为4 KiB时，才会对200 OK响应进行转码。切片子请求、使用上游主动压缩的响应、范围请求、预压缩响应、长度未知的主体和二进制内容将保持不变。

4 KiB阈值过滤了大量微小请求，仅排除了约1%的其他符合条件的字节。降低阈值会增加每个对象的开销，但节省的存储空间有限。

阈值和zstd压缩级别均为参数而非永久限制。我们最初选择zstd级别3和4 KiB最小值，因为它们为我们提供了一种保守的架构评估方式。在初步了解CPU预算后，我们可以测试更高压缩级别是否能显著提升压缩比以证明其额外成本的合理性。

通过缓存处理超过一百万次请求

我们针对受控测试环境对原型进行了验证，并通过请求日志、Prometheus指标和Jaeger追踪关联了每个请求。

正确性测试涵盖了缓存未命中、缓存命中、单跳填充、分层缓存填充等场景。我们通过调整缓存键使每个请求遵循特定路径，并利用追踪确认编码和解码发生的位置。

一项性能测试向10台缓存服务器发送了超过一百万次请求。其中一半在禁用分层缓存的情况下运行，另一半在启用分层缓存的情况下运行。这使我们能够将本地缓存行为与缓存层级间传输的测量结果分开评估。

这两个测试资产大小分别为约195 KiB和272 KiB，压缩比例均约为2.8倍。这是故意选择的可压缩测试数据集。它为我们验证架构提供了明确的信号，但它并不能代表互联网上的所有文本对象。在将测量的压缩比视为全量常数之前，需要更广泛的数据集进行验证。

压缩一次，受益多次

这项实验表明，我们仍可以在缓存服务中部署显著的效率优化，使所有客户受益。我们为缓存转码构建的方案表明，在我们测试的条件下，这种权衡是划算的。架构保持了内容完整性并控制在CPU预算范围内。

下一步计划评估更高zstd压缩级别，测试更广泛的内容类型和对象尺寸，调整资格条件中的不同参数等。未来工作还可研究范围请求、预压缩源响应，以及将压缩对象直接传递给已支持该格式的下游组件而无需解码。

在整个实习期间，我有幸与Cloudflare的工程团队合作，参与构建了存储和分发全球网络内容的真实基础设施。如果你想通过参与建设更好的互联网开启职业生涯，请查看我们的实习机会和招聘职位。

目录列

讨论列

相关标签及社交媒体链接

相关标签

关注社交媒体

• Cloudflare

电子邮件订阅