背景与问题

Cloudflare 的 DNS 传播流水线中，Zone Builder 负责将数据库中的区域变更转换为边缘权威 DNS 可用的数据并写入 Quicksilver。2022 年其每秒处理约 250 条 DNS 记录变更，如今已达约 700 条，叠加约 100 个其他事件。部分区域记录数超 2000 万，且仍在增长。

原有全量构建方式每次均需读取、编码并比对所有记录，且全程在内存中持有整个区域。对于超大规模区域，全量构建已无法在内存中完成，成为明显瓶颈。

定向构建方案

团队构建了定向构建规划器与新的调度器，仅选择可证明安全的最小构建范围，并合并同一区域的工作：

  • 事件生产者补充变更的 zone 字段与设置及新旧值；
  • 规划器将输出区分为记录键与共享元数据键，对应五种构建类型：仅资源、资源加元数据、 apex 加元数据、清除、全量区域；
  • 无法证明更小范围安全的变更仍走全量构建，但超阈值大区域禁止升级为全量，只重建 apex、元数据及已识别名称；
  • 调度器合并同区域任务，避免重复开销。

成效

区域设置变更不再触发数千万记录级重建。整体峰值内存降低 85%，释放的冗余容量使流水线原有为保障弹性而设置的等待时间得以缩短，DNS 变更到 Quicksilver 数据写入的时延减半。

对读者的意义 / 技术解读

对于运维与 SRE 而言，该实践说明当权威 DNS 规模持续增长时，全量重算模型必然触及内存与时延天花板。其核心思路——为事件附加语义、以「最小可证明安全」原则做增量构建、并对超大规模对象设置全量禁用阈值——同样适用于自研配置下发、控制面到数据面同步系统。在 DNS 安全层面，精确的范围控制也降低了因构建排队阻塞导致的边缘数据陈旧风险。