8月29日，Cloudflare发布技术博客，宣布通过对旗下Big Pineapple平台的DNS缓存数据结构进行系统性优化，成功释放约100TB的内存资源。Big Pineapple是支撑Cloudflare 1.1.1.1、Gateway DNS、DNS Firewall、AS112等多项DNS服务的核心平台，任何时刻均存储超过2500亿条DNS缓存条目。在这一规模下，每条缓存记录哪怕仅多占用1字节，整个集群就会额外消耗超过250GB内存。
此次优化未依赖任何新硬件投入，完全通过对Rust语言编写的数据结构进行重构实现。DNS缓存由键值对组成，键用于标识查询的域名、记录类型、认证状态等信息，值则保存DNS响应的网络数据、权威和附加记录，以及创建时间、TTL和命中次数等元数据。Cloudflare的优化从多个维度对数据存储方式进行了精简。
优化首先针对Rust中Vec和String的内存开销展开。由于DNS响应写入缓存后不会继续修改，Vec用于动态扩容的capacity字段已无必要。Cloudflare将相关结构替换为Box<[T]>和Box<str>，减少每个字段8字节的开销，同时避免为后续扩容预留额外空间。每个缓存条目中共有8个相关的Vec和String字段，这一调整理论上可使每条记录减少64字节。按照超过2500亿条缓存记录计算，仅这一项优化带来的累计节省就超过15TB。
随后，Cloudflare减少了DNS响应中多个列表产生的指针开销。原本数据、权威和附加记录分别存储在不同列表中，现在改为使用单个列表，并通过偏移量标记不同区域的起始位置。由于DNS记录数量可以使用u16表示，相关字段从指针和长度信息改为更小的偏移量，每个缓存条目又节省了28字节。此外，Cloudflare还针对DNS记录中的owner字段进行了优化。多数情况下，记录所属域名与用户查询的域名完全相同，因此缓存时无需重复保存。只有CNAME等情况下记录所属域名不同，才会额外保存完整域名。读取缓存时，如果owner字段为空，则直接使用缓存键中的查询域名恢复。
Cloudflare还调整了Rust枚举enum的存储方式。原有RecordData枚举需要按照最大成员NAPTR的大小分配空间，导致常见的A和AAAA记录也要承担大量未使用的空间。由于A、AAAA记录占全部流量的80％以上，这种设计造成了明显浪费。优化后，Cloudflare将较大的TXT、NAPTR、SVCB等枚举成员放入堆内存，而A、AAAA等体积较小且常见的记录继续直接存储，使A记录每条节省120字节。不过，单独进行堆分配也会带来分配器开销和内存局部性下降等问题，因此Cloudflare继续调整了数据布局。
最终，Cloudflare将DNS记录的数据部分直接保存为连续的原始字节，不再为每种记录建立单独的解析后对象。每条记录由长度信息和原始数据组成，并集中存储在一个Box<[u8]>中。这种方式取消了此前每个记录对应的枚举和独立堆分配，同时让数据连续排列，有利于CPU缓存命中。对于A、AAAA、TXT以及DNSSEC记录，生成DNS响应时可以直接复制已经编码的数据，无需重新逐字段序列化。CNAME、NS、MX、SOA等包含域名的记录仍需要解析，以便应用DNS名称压缩。测试显示，这种数据布局使缓存查询延迟进一步降低约5％。由于缓存写入使用可重复利用的临时缓冲区，记录数据通常无需反复扩容，这一操作还使缓存插入吞吐量单独提升了13％。
这些优化已于2026年5月18日开始逐步部署，并于7月6日完成在所有相关服务中的推广。生产环境数据显示，实例内存使用量在不同阶段持续下降。在p99情况下，单实例常驻内存从9.3GB降至5.3GB，减少43％；p90则从6.5GB降至3.8GB，减少42％，缓存越满的实例省得越多。基准测试中，这5项优化将单条缓存记录的内存占用从953字节降至420字节，总计减少56％；每条记录对应的内存分配量则从1.1KB降至461字节，减少58％。缓存插入吞吐量从每秒62.5万条提高至89.3万条，提升43％；缓存查询延迟从828纳秒降至670纳秒，降低19％。在生产环境中，由于常驻内存还包括缓存以外的进程数据，因此实际降幅小于单条缓存记录的基准测试结果。
所有优化完成并趋于稳定后，Cloudflare整个服务集群的工作集内存约减少100TB。Cloudflare表示，后续计划利用释放出来的内存扩大DNS缓存容量，同时不增加整体内存使用量，以提高缓存命中率并减少向上游DNS服务器发起的查询请求。这一优化路径展示了在超大规模基础设施中，通过精细的数据结构设计实现资源效率提升的可行性，对同类DNS服务及高频查询系统的架构设计具有参考意义。
该文观点仅代表作者本人，企服科学平台仅提供信息存储空间服务。
