Cloudflare测试缓存转码或释放PB级缓存容量

Cloudflare正在测试一种名为“缓存转码”的原型方案，计划在符合条件的未压缩文本写入磁盘缓存前，先使用Zstandard进行无损压缩，主要面向HTML、JSON、CSS和JavaScript等内容。该公司估计，方案成熟后可能为现有基础设施释放PB级有效缓存空间，但仍需经过更广泛的验证。

这套机制只在资源首次进入缓存时执行一次编码，后续请求复用压缩数据，直到实际向客户端提供服务时才解压。在测试中，符合条件的内容体积平均减少约64%，因此既能让服务器容纳更多对象，也能减少缓存数据在不同数据中心之间传输所需的带宽。

实现方面，Cloudflare将Facebook为实时应用设计的Zstandard算法接入基于Rust构建的Pingora代理框架。其评估认为，只需付出较小的CPU处理成本，就可能换来PB级缓存容量和持续的跨数据中心传输节省；一次编码产生的开销，会被后续多次读取摊薄。

该功能不会对所有响应进行处理，仅针对成功返回、包含可压缩文本且大小至少为4 KiB的未压缩响应。范围请求、已经预压缩的内容、二进制数据以及大小未知的响应均被排除。4 KiB门槛可以避免处理大量小对象，仅舍弃约1%的符合条件数据；门槛和Zstandard压缩级别也都能按CPU性能与存储空间之间的取舍进行调整。

Cloudflare指出，图像、视频和字体等媒体通常已经经过压缩，重复处理只会浪费CPU。在其流量样本中，这类媒体占请求数的21.4%，却占总字节数的63.3%。相比之下，可压缩文本占请求总数的67.3%、占总字节数的22.3%，其中约71%的内容到达时仍未压缩，并且能够有效压缩。

部分开发者认为，用“转码”描述这种编码与解码流程并不准确，另一些讨论则集中在压缩对象的选择上。有人提出，如果目标是降低解码阶段的CPU消耗，或许更适合压缩冷数据；也有人询问，范围请求在不压缩时可以直接读取完整文件的对应片段，启用该方案后应如何处理。

Cloudflare分别在启用和关闭分层缓存的条件下进行测试，以衡量压缩对本地缓存命中以及缓存层之间数据传输的影响。目前原型仍处于开发阶段，后续将继续比较不同压缩级别、内容类型、对象大小和缓存场景下的表现。