DNS 缓存 TTL：从分钟级到秒级的博弈

引言

在分布式系统设计中，DNS 缓存 TTL（Time To Live）看似是一个简单的配置参数，但在不同流量规模下，它所承载的设计权衡完全不同。百万 QPS 系统可以"悠闲"地使用 300 秒甚至更长的 TTL；而千万 QPS 系统却陷入两难——长 TTL 导致故障切换迟缓，短 TTL 则引发客户端解析风暴。

这不是简单的参数调优问题，而是系统架构层面的本质差异。

一、TTL 的核心作用与基本权衡

DNS TTL 决定了客户端缓存 DNS 解析结果的有效期。在这个时间窗口内，客户端直接使用缓存的 IP 地址，无需重新解析。

TTL 设计的基本权衡：

对于百万 QPS 系统，这个权衡相对简单：选择较长的 TTL，牺牲一定的故障切换速度，换取系统的稳定性。但当流量规模跨越到千万 QPS 时，这个平衡被彻底打破。

二、百万 QPS：长 TTL 的"舒适区"

在百万 QPS 场景下，假设系统服务 100 万活跃用户，采用 300 秒的 TTL：

故障场景分析：

• 最坏情况下，故障切换需要等待 300 秒

• 300 秒内的流量损失 = 100 万 QPS × 300s = 3 亿次请求（理论最大值）

• 实际上，由于客户端缓存时间分布均匀，平均损失约为理论值的一半

对于百万级系统，这个损失通常在可接受范围内。更重要的是，业务往往有其他容错机制（如客户端重试、多机房部署）来缓解 DNS 切换延迟的影响。

长 TTL 的优势：

1. 客户端解析压力可控：每个客户端平均每 300 秒解析一次

2. 连接建立延迟稳定：绝大多数请求命中本地缓存

3. 架构简单：无需额外的 DNS 优化方案

三、千万 QPS：短 TTL 的"必选项"与"代价"

当系统规模达到千万 QPS，服务 1000 万+活跃用户时，故障切换时间成为关键指标。

为什么必须缩短 TTL？

以 300 秒 TTL 计算故障影响：

• 最坏情况流量损失 = 1000 万 QPS × 300s = 30 亿次请求

• 假设单次请求价值 0.001 元，直接损失 300 万元

• 更严重的是用户体验损伤和品牌影响

因此，千万 QPS 系统通常将 TTL 缩短到 30-60 秒，甚至更短。但这引发了新的问题。

短 TTL 的连锁反应：

假设将 TTL 从 300 秒缩短到 30 秒，客户端的 DNS 解析频率提升 10 倍。虽然单次 DNS 解析延迟通常只有几十毫秒，但在千万级用户规模下，这会带来两个隐性成本：

1. 首次连接延迟的"放大效应"

在短 TTL 策略下，更多请求会触发 DNS 解析。对于延迟敏感型业务（如实时通信、支付），这意味着更高比例的请求需要承担额外的解析延迟。

1. 缓存过期的"时间窗口集中"问题

如果大量客户端在相近时间启动（如 App 推送后的打开高峰），它们的 DNS 缓存会在相近时间过期，形成解析请求的周期性波峰。

四、递归解析压力的数学模型

从客户端视角建立简化模型，分析不同 TTL 策略下的解析行为：

基础假设：

• 活跃用户数：N

• DNS 缓存 TTL：T 秒

• 单用户平均请求间隔：I 秒

客户端 DNS 解析频率估算：

当 I < T 时（用户活跃期间缓存有效）：

• 单用户解析频率 ≈ 1/T 次/秒

• 系统总解析频率 ≈ N/T 次/秒

具体数字对比：

可以看到，千万 QPS 系统采用短 TTL 后，客户端 DNS 解析请求量达到 33 万 QPS 级别。这个压力需要在架构层面妥善处理。

五、千万 QPS 的 TTL 治理方案

针对短 TTL 带来的挑战，千万 QPS 系统通常采用以下架构策略：

1. HTTPDNS 替代传统 DNS

将 DNS 解析从系统层面上移到应用层，通过 HTTP 协议直接查询自建的 DNS 服务：

• 解析结果可精细控制缓存策略

• 支持基于业务逻辑的智能调度

• 避免 LocalDNS 的不可控因素

2. 客户端智能缓存策略

突破 TTL 的刚性限制，实现更灵活的缓存机制：缓存有效性 = TTL 过期检查 + 后端健康检查 + 备用 IP 池

• 乐观缓存：TTL 过期后不立即失效，而是异步刷新

• 健康感知：根据实际连接成功率动态调整 IP 优先级

• 多 IP 容灾：缓存多个 IP，主 IP 失败时快速切换

3. 长连接复用

减少 DNS 解析的根本方法是减少连接建立次数：

• HTTP/2 多路复用

• 连接池管理

• WebSocket 长连接

在千万 QPS 系统中，长连接复用率通常需要达到 90% 以上，才能将 DNS 解析的影响控制在可接受范围内。

4. 分层 TTL 策略

根据业务特性采用差异化 TTL：

六、本质差异总结

核心结论：千万 QPS 不是百万 QPS 简单乘以 10。在 DNS TTL 这个维度上，它意味着从"配置参数调优"升级为"架构方案设计"，需要 HTTPDNS、智能缓存、长连接复用等多个子系统协同工作，才能在"快速故障切换"和"解析压力可控"之间取得平衡。