Cloudflare 将 1.1.1.1 DNS 缓存的内存占用削减了 100TB

Cloudflare 将 1.1.1.1 DNS 缓存的内存占用削减了 100TB — infoq.cn · 13 小时前 · ⚙️ 工程

1.1.1.1 这类公共 DNS 解析器每天要处理海量查询，缓存是把响应时间压到毫秒级的关键，同时也是服务端内存消耗最大的模块之一。Cloudflare 的工程师在官方博客中说明，他们通过重构递归解析器的 DNS 缓存内存布局，让整个机队在这一模块上省下了约 100TB 内存。问题的根源并不在应答数据本身：每一条被缓存的记录，除了要存放 DNS 报文的原始字节，还要额外承担哈希表桶、堆分配头、引用计数、TTL 过期信息以及淘汰链表节点等开销，这些固定成本随缓存条目数线性增长，最终在数千台服务器上被放大成机队级别的账单。团队的做法是把数据和围绕数据的管理结构拆开，用紧凑的连续槽位统一存放条目，把淘汰所需的顺序信息编码进索引本身，并让内容相同或高度相似的 RRset 共享同一份存储，同时保持原有的命中率与解析延迟不变。对解析器来说，内存预算直接决定单机能容纳多少条目：条目越多命中率越高、回源上游的查询越少，但内存成本也越高，因此这项优化同时改善了成本结构和容量上限。为了避免重构引入回归，团队还用真实流量回放，对照命中率、延迟与内存三组指标验证效果。他们的结论是，缓存优化里最容易被忽视的不是压缩单条报文，而是砍掉围绕每条报文的那些看不见的固定开销，这一思路对所有高基数缓存都具有参考价值。

核心信息

1.1.1.1 解析器跑在 Cloudflare 遍布全球的众多节点上，缓存是这个服务里最吃内存的组件之一；重构之后，整个机队在 DNS 缓存上少用了约 100TB 内存，而命中率与解析延迟这两项关键指标没有出现退化，也就是说收益来自内存布局的调整，而不是靠缩小缓存规模或缩短条目存活时间换来的。对以免费公共解析服务为主打的 1.1.1.1 来说，这部分节省直接对应服务器采购与电力开销，也让单机在同样内存预算下能装下更多条目。
具体做法是把缓存条目的数据与围绕数据的管理结构拆开：DNS 报文本身仍按原样存放，但哈希索引、TTL 过期信息、淘汰顺序等元数据被收拢进紧凑的连续槽位，用索引编码替代每条目一个链表节点，并让内容相同或高度相似的 RRset 共用一份存储，从而把每条记录的平均字节数压下来。这种布局同时减少了内存分配器的调用次数和指针追逐，对高并发查询下的缓存访问路径也更友好。
和传统实现相比，典型的 DNS 缓存会采用哈希表加每条目一个 LRU 链表节点的结构，再配合一次独立的堆分配，这些固定开销在报文只有几十到几百字节时显得格外沉重，甚至可能超过数据本身；本次优化瞄准的正是这部分与条目数量成正比的成本，因此缓存越大、条目越多，节省就越明显，这也是总量能累积到 100TB 量级的原因。代价则是数据结构更复杂，实现与验证的门槛明显更高。

💡 为什么值得读: 推荐理由：它用一个具体到字节的重构案例，讲清了缓存成本真正花在哪里，读完你会重新审视自己系统里那些看不见的每条目固定开销。

✍️ 小编看法: 小编看法：100TB 这个数字之所以有冲击力，不是因为它大，而是因为它来自一个我们通常认为已经足够简单的组件——一个 DNS 缓存。很多团队做容量规划时，习惯把注意力放在数据本身的大小上，却很少去算每条记录背后的固定开销：一次独立分配、一个链表节点、一份重复的元数据。单条看起来只是几十字节，乘以每天数十亿次查询沉淀下来的条目数，就变成了整机队的账单。这次优化的价值在于，它把成本模型从「压缩内容」换成了「压缩结构」，而这一思路可以平移到任何高基数缓存上，比如 TLS 会话票据、HTTP 响应缓存、限流计数器、边缘规则状态，这些地方同样存在大量被浪费的簿记空间。

不过代价也真实存在。把数据和管理结构拆开、用索引编码替代指针，意味着更复杂的并发控制和更难的调试：一旦边界算错，问题会以内存踩踏或缓存错乱的形式出现，而且很难在小规模测试里复现，通常要等到线上流量达到某个量级才暴露。省下来的内存究竟会被用来扩大缓存、提高命中率，还是被折算成更低的运营成本，取决于各家厂商的取舍——前者对用户更友好，后者对财报更友好，而这两者并不总是同向。接下来值得观察的是，这类内存布局的经验会不会被沉淀成可复用的库，或被其他解析器项目跟进；以及在内存价格持续走高、边缘节点规模不断扩大的背景下，「更省」会不会像当年的「更快」一样，成为基础设施团队新的核心考核指标。

🏷️ Cloudflare, DNS, memory, performance