我们将 DNS 构建延迟减半，并将内存使用量降低 85%

把区域设置变更纳入定向构建

Cloudflare 于 2026 年 11 月 2 日公布的资料称，DNS 区域构建器（Zone Builder）已将区域设置变更纳入定向构建，不再为此重建整个区域。官方称，此举将峰值内存使用量降低 85%，并利用新增余量缩短管线为韧性保留的等待时间，使 DNS 变更到数据写入 Quicksilver 的时间减半。2022 年该系统每秒接收约 250 条记录变更，如今约 700 条，另有约 100 条其他事件；部分区域已超过 2000 万条记录。

只选择能够证明安全的最小工作集

事件现在会携带被修改的字段、设置及可获得的新旧值。规划器据此选择五种构建方式：仅重建指定 DNS 名称；重建名称与共享元数据；重建区域顶点（裸域名）与元数据；清除不再发布的区域；无法证明安全时重建整区。A、AAAA、TXT、CNAME 等普通变更通常采用第一种，名称服务器和通配符变更采用第二种，Universal SSL 等设置可能采用第三种。

这种方案适合影响范围明确的变更，但不会为减少工作量而冒险。若事件只更新时间戳、缺少细节、类型未知，或可能影响区域内任意记录，仍会触发整区构建。定向构建写出的每个键必须与整区构建逐字节一致；无法证明这一点时，系统会采用更保守的路径。

同名区域与数据时序带来的限制

Quicksilver 为每个区域分别保存记录键，却让同名区域共享一份元数据键。构建器因此需要在执行前读取最新发布快照，重新确认区域设置、当前网络是否应发布该区域，以及哪些同名区域 ID 应进入元数据。事件还可能早于数据库副本可见，系统会留出正常复制延迟，并在执行前再次检查。

• 统一调度器会合并同一区域的事件；任一事件要求整区构建，合并结果就会升级，清除操作则优先。
• Kafka 使用软提交，重试可能重复工作，但不会越过尚未完成的消息推进提交位置；新变更还需等待下一次区域重建。
• 超过固定记录数阈值后，系统不会升级为整区构建，而会重建顶点、元数据和事件涉及的名称；少数场景可人工重建指定名称。

以逐键比较验证输出一致性

官方通过等价测试、镜像环境逐键比较和抽样检查验证输出。镜像环境读取生产事件与数据库状态，但不承载客户流量；比较器检查 20% 区域是否出现键缺失、额外键或值差异。上线时按区域名哈希逐步扩展调度范围，避免两个调度器同时改写同名区域的共享元数据。

24 小时统计中，86.81% 的构建仅处理资源，2.54% 处理资源与元数据，2.30% 处理顶点与元数据，1.30% 为清除，合计 92.95% 避开完整区域重建。上述性能、延迟和比例均为 Cloudflare 官方测量，主要适用于其能够识别变更范围、更新频率和区域规模的场景，并不意味着所有 DNS 变更都能获得同等幅度的延迟下降。

资料来源：How we halved DNS build delay and cut memory use by 85%（2026-11-02）。