孤本网
发布于 2026-09-23 / 0 阅读
0
0

标题:Cache Transcoding 技术通过 Zstandard 压缩为 Cloudflare 带来 PB 级额外存储

Cache Transcoding 是 Cloudflare 开发的原型技术,它通过将未压缩的文本响应使用 Zstandard 压缩再存入缓存,为现有的服务器和数据中心带来了 PB 级的有效缓存容量扩展,并减少了网络传输的数据量,目前该技术正处于持续开发与优化中。

关键要点

  • Cache Transcoding 技术通过 Zstandard 算法,让现有的缓存服务器有效存储容量额外提升了 PB 级别。
  • 该技术仅针对满足大小不低于 4 KiB、成功返回且包含可压缩文本的响应进行压缩处理。
  • 压缩过程仅需在内容首次进入缓存时执行一次,后续获取时仅消耗少量的解压 CPU 资源。
  • 使用 4 KiB 作为压缩阈值,既避免了处理海量小对象,也仅让约 1% 的符合条件数据失去压缩机会。
  • 图像、视频和字体等媒体内容占总字节数的 63.3%,它们通常已经过压缩,Cache Transcoding 技术不对其进行重复压缩。

背景与事实

根据 InfoQ 的报道,超大规模云服务提供商 Cloudflare 最近公开了其名为“缓存转码”(Cache Transcoding)的技术原型。这项技术的工作机制非常明确:在符合条件的未压缩文本内容(例如 HTML、JSON、CSS 和 JavaScript 等)被正式写入磁盘之前,系统会先使用 Zstandard(Zstandard)算法对数据进行无损压缩。这项技术依托于 Facebook 专为实时应用开发的 Zstandard 算法,并深度整合了 Cloudflare 自主构建的基于 Rust 语言的代理框架 Pingora。据该云服务提供商内部的估算,这套原型方案能够在不增加物理硬件的前提下,额外释放出 PB 级别的可用缓存空间。

为了验证该技术的有效性并量化其影响,研究团队在启用和禁用的分层缓存架构下分别进行了测试,旨在度量压缩机制对本地缓存命中以及各个缓存层之间数据传输量的具体影响。团队在流量样本中发现,图像、视频和字体等媒体内容占据了请求总数的 21.4%,但占总数据字节数的 63.3%。由于这类内容通常在上游就已经被高度压缩,再次使用 Zstandard 进行转码反而会白白消耗服务器宝贵的 CPU 资源。因此,该功能的触发机制被设定为极其严格的过滤条件。

具体而言,Cache Transcoding 功能仅对未压缩响应进行压缩,且响应必须同时满足:包含可压缩文本、请求状态码为成功(例如 200),并且返回的数据大小不低于 4 KiB 阈值。同时,该功能会严格排除范围请求(Range requests)、上游已经预先压缩的内容、纯二进制文件,以及文件大小未知的响应。开发人员在技术文档中指出,设定 4 KiB 的阈值是一项重要的工程权衡,它直接避免了海量微小对象对 CPU 造成的不必要消耗。虽然这个过滤条件会导致约 1% 符合条件的小体量数据无法享受转码红利,但对于整体存储效益的影响微乎其微。同时,开发团队强调,这个 4 KiB 阈值以及 Zstandard 的压缩级别参数都设计为可动态调整状态,以便运维人员能够根据实际节点 CPU 算力与剩余存储空间的比例,随时找到最优的运行配置。

影响分析

对于中国云原生开发者、后端架构师以及从事边缘计算与 CDN 优化的从业者而言,Cache Transcoding 这一前沿实践具有直接的参考价值和深远的方法论意义。首先,它提供了一种低代码复杂度的扩容思路:通过引入先进的算法并精细调优阈值,可以在不采购新硬件的情况下,显著提升边缘节点的单机容量。其次,Zstandard 结合 Rust 框架 Pingora 的底层组合,展示了在极致性能要求下,如何最大化利用 CPU 周期。架构师在设计自己的 CDN 或大型高并发网关时,需要明确理解“转码”并非对所有流量一视同仁地处理,而是必须通过严格的过滤器(如排除已压缩的媒体、截断 4 KiB 以下的极小文件)来保护后端的 CPU 资源。这种“有选择地压缩”的思路对于优化国内企业自建 CDN 的存储成本和带宽传输开销提供了极具价值的工程范例,提示从业者在面对海量异构数据时,精准识别高收益、低成本的优化切入点才是提升系统整体效能的关键。

适用边界

必须严格指出,Cache Transcoding 技术的收益模型完全依赖于对“未压缩文本数据”的处理。因此,对于那些以传输高清视频、3D 渲染文件、大型无损音频或已经是高度压缩态的图像(如 WebP、AVIF、Brotli 压缩后的文本)为主的边缘节点场景,该技术的适用性将大打折扣,甚至可能因为强行解压和再压缩而增加 CPU 负担,导致延迟恶化。此外,该技术的性能表现建立在 Cloudflare 特有的 Rust 代理框架 Pingora 的高效执行环境之上,如果缺乏类似的底层性能优化,单纯的 Zstandard 压缩在延迟极度敏感的超实时链路中可能无法完全满足要求。同时,该原型系统目前仍在持续开发中,尚未形成完整的生产级功能,针对各种极端异常场景(如频繁变动的对象内容导致缓存反复失效)的处理策略也尚未完全公开。

孤本观察

在技术讨论层面,尽管社区部分专家对使用“转码”(Transcoding)一词来描述无损压缩与解压过程产生了严格的术语争论(通常转码涉及有损的格式转换或编码变更),但这种学术上的术语争议并不掩盖该架构设计在工程落地上的巨大价值。通过极其保守的 4 KiB 过滤阈值和精准的数据采样,Cloudflare 展示了在超大规模集群中如何利用微小且可控的 CPU 计算开销,精准换取 PB 级别的基础设施成本下降与能效提升,这种基于严密工程数据驱动的架构权衡方式,比单纯追求理论极限的激进算法,更值得底层云计算平台在设计核心特性时参考。

标题:Cache Transcoding 技术通过 Zstandard 压缩为 Cloudflare 带来 PB 级额外存储

标题:Cache Transcoding 技术通过 Zstandard 压缩为 Cloudflare 带来 PB 级额外存储

标题:Cache Transcoding 技术通过 Zstandard 压缩为 Cloudflare 带来 PB 级额外存储

标题:Cache Transcoding 技术通过 Zstandard 压缩为 Cloudflare 带来 PB 级额外存储

标题:Cache Transcoding 技术通过 Zstandard 压缩为 Cloudflare 带来 PB 级额外存储

常见问题

Cache Transcoding技术中触发压缩处理的响应需要满足哪些具体条件?

响应必须是未压缩的、包含可压缩文本、状态码为成功(如200)且数据大小不低于4 KiB。

该技术方案中设定的4 KiB压缩阈值主要解决了什么问题?

该阈值避免了处理海量微小对象对CPU造成的不必要消耗,同时仅让约1%符合条件的小体量数据失去压缩机会。

为什么Cache Transcoding技术不对图像、视频等媒体内容进行重复压缩?

因为媒体内容通常在上游已高度压缩,再次转码会白白消耗CPU资源,且其占总字节数63.3%。

使用Cache Transcoding技术后,压缩过程对服务器CPU资源的消耗有什么特点?

压缩仅在内容首次进入缓存时执行一次,后续获取时仅消耗少量的解压CPU资源。

该技术的性能表现依赖于哪个具体的底层框架?

该技术深度整合了Cloudflare自主构建的基于Rust语言的代理框架Pingora。

来源:InfoQ 中文 AI


评论