DNS预热：从可选到必选如果你的团队开始讨论"发布前要不要预热 DNS"，说明系统正在跨越一个临界点。关注我，聊聊千万

千万 QPS 的系统不是一夜之间建成的。从第一个用户到千万级并发，DNS 缓存会随着业务增长自然地被"养热"——LocalDNS 逐层建立缓存，应用内 DNS 缓存也趋于稳定。在这个渐进过程中，你几乎感受不到 DNS 的存在。

然而，当系统规模跨过某个临界点后，以下场景会让 DNS 冷启动问题突然暴露出来：

这些场景在百万 QPS 时代可能只是监控图上的一个小毛刺，但在千万 QPS 时代，它们会变成足以影响系统稳定性的风险点。

理解这个问题，需要先建立一个简化模型。

假设一个后端服务需要访问 5 个下游依赖（数据库、缓存、消息队列等），每个依赖对应一个域名。在进程冷启动时，这 5 个域名都需要解析。

看起来只是 10 倍的差异？问题在于时间窗口。

百万 QPS 系统做滚动发布，2,000 个实例分 20 批，每批 100 个，间隔 30 秒。DNS 查询被均匀分散到 10 分钟内，峰值查询量约 500 次/批 × 2 批/分钟 = 1,000 QPS，企业内部 DNS 服务轻松承受。

千万 QPS 系统呢？20,000 个实例分 20 批，每批 1,000 个。即使同样的发布节奏，峰值查询量变成 5,000 次/批 × 2 批/分钟 = 10,000 QPS。如果发布窗口压缩（业务压力下很常见），这个数字还会成倍增长。

更棘手的是级联效应：当内部 DNS 服务响应变慢，应用启动超时，触发重试，DNS 压力进一步放大。在极端情况下，这种正反馈可能导致整个发布流程卡住。

DNS 预热的本质是将瞬时的查询压力分散到更长的时间窗口。根据缓存层级的不同，可以建立三层防线：

大多数语言的 DNS 解析库都有内存缓存，但默认行为差异很大：

在千万 QPS 系统中，推荐在应用启动阶段主动预热关键域名。

关键点：预热应在流量接入之前完成，避免首批请求承受 DNS 解析延迟。

在每台机器上部署轻量级 DNS 代理（如 dnsmasq、CoreDNS），可以实现：

配置示例（dnsmasq）：

最小缓存时间 300 秒，即使上游返回更短 TTL

min-cache-ttl=300

cache-size=10000

对于超大规模系统，可以在数据中心层面部署专用的 DNS 缓存集群：

这一层的关键价值是：在大规模冷启动前，可以通过预热脚本提前将热点域名加载到缓存集群。

仅有缓存还不够，发布时序的精细控制同样重要。以下是一个千万 QPS 系统发布前的 DNS 预热时序：

几个关键设计点：

DNS 预热从"可选优化"变成"必选流程"，是千万 QPS 系统的一个典型特征。这不是简单的规模放大，而是系统运维模式的质变：

当你发现团队开始讨论"发布前要不要做 DNS 预热"时，说明系统可能正在跨越这个临界点。这是一个好信号——也是一个需要认真对待的信号。