Cloudflare最近在测试一个叫“缓存转码”的原型方案：在缓存内容落盘之前，先用Zstandard算法压缩一遍。符合条件的文本响应会以压缩形态存放，预计能释放PB级的缓存空间，同时减少数据中心之间的传输量。目前这项功能还在原型阶段，需要更大规模的验证。
缓存转码到底做了什么？
说白了，就是把原本要“原样存盘”的缓存文件，先压缩然后再放进去。Cloudflare的CDN节点遍布全球，缓存的内容越多，命中率自然越高，可存储和带宽成本也跟着涨。缓存转码的思路是：别让磁盘塞满未压缩的HTML、JSON、CSS和JavaScript，改用Zstandard把这些文本压缩到更小的体积。等到用户请求时，再解压返回。
这个动作只在内容首次进入缓存时发生一次，之后每次命中缓存，都能省下存储和带宽。也就是说，额外的CPU开销被摊薄了，而省下来的空间是实打实的。
哪些内容会被压缩？规则其实挺严
并非所有响应都值得压。Cloudflare设了四个条件：大小不低于4KiB、请求成功、包含可压缩文本、并且当前是未压缩状态。下面这些情况会被排除：范围请求、预压缩内容（比如服务器已经发来的gzip文件）、二进制内容，以及大小未知的响应。
- 大小不低于4KiB，是为了避开海量小对象。小文件压缩收益低，还白白浪费CPU。
- 只处理未压缩响应，避免重复压缩，省下的CPU可以做别的事。
- 排除范围请求，因为这类请求往往只取部分数据，压缩后反而难以定位。
有意思的是，设了这个阈值之后，系统只放弃了约1%的合格数据。换句话说，大部分值得压缩的文本响应都被覆盖了。
为什么说“只压一次”很划算？
压缩本身要消耗CPU，但缓存转码的精妙之处在于：成本放在了“第一次写入”这个一次性环节上。后续无论缓存被读多少次、传输到多少个边缘节点，省下的都是反复出现的存储和带宽开销。对于热门的文本资源来说，“一次开销、多次受益”的模式确实划算。
阈值和Zstandard压缩级别都可以调。如果你觉得CPU很闲，可以把压缩级别调高一些，换取更多存储空间；如果存储充足，也可以调低级别来减少延迟。这种灵活性让运维人员能在CPU和存储之间做精细的权衡。
流量数据：可压缩文本其实非常多
Cloudflare统计了真实流量：图像、视频、字体这类已经压缩过的媒体，占请求数的21.4%，却占了总字节数的63.3%。也就是说，大部分流量是压不动的二进制媒体。而HTML、JSON、CSS、JavaScript这类可压缩文本，占请求数的67.3%，其中约71%到达时未压缩，且能有效压缩。
这说明什么？只要把文本压缩好，缓存里能腾出来的空间会非常可观。PB级有效缓存容量的增加，并不是空话。
测试方案与未来方向
为了评估效果，Cloudflare在启用和禁用分层缓存的条件下分别测试，观察压缩对本地缓存命中率以及缓存层之间传输量的影响。原型还在开发中，后续会测试不同压缩级别、不同内容类型、不同对象大小和缓存场景。
这项技术如果成熟了，对整个CDN行业都有参考价值。对国内企业来说，缓存策略也是上云时必须考虑的一环。很多开发者习惯直接买一台云主机就开跑，但流量一上来，带宽和存储成本往往超出预期。与其事后焦虑，不如提前看看缓存压缩这类优化手段。
如果你正在规划企业上云，不妨把缓存设计纳入架构。作为阿里云代理商，易枫顺 - 阿里云官方旗舰级代理商 能提供上云方案参考。至于成本控制，还是得从存储和带宽这类细节里抠。
FAQ
Q: 缓存转码会影响用户访问速度吗？
A: 正常情况下影响很小。压缩只发生在首次写入缓存时，之后每次读取只需要解压，而Zstandard的解压速度很快。如果担心CPU消耗，可以通过调节压缩级别来控制。
Q: 为什么只处理大于等于4KiB的内容？
A: 小对象压缩后体积变化不大，但压缩和解压的开销是实打实的。设这个阈值可以避免浪费CPU处理大量小文件，而且只舍弃约1%的合格数据，性价比很高。
Q: 这项功能什么时候正式上线？
A: 目前还是原型阶段，Cloudflare会在不同条件下测试，包括压缩级别、内容类型、对象大小和缓存场景。上线时间没有明确说法，但方向是确定的。
Q: 普通网站能用上类似思路吗？
A: 可以。比如在源站提前用Zstandard或Brotli压缩文本资源，或者利用CDN的边缘压缩功能。就算不换成Cloudflare，自己用服务器时也能通过配置Nginx压缩和缓存头来达到类似效果。
关于易枫顺
深圳市易枫顺网络科技有限公司是阿里云官方旗舰级代理商。提供云服务器ECS、云数据库RDS、对象存储OSS等阿里云全系产品官方特惠折扣与代金券申请，以及多云成本优化、企业上云一站式服务。客服热线：19520841949 - 易枫顺
来源：InfoQ
