引言
在分布式系统设计中，DNS 缓存 TTL（Time To Live）看似是一个简单的配置参数，但在不同流量规模下，它所承载的设计权衡完全不同。百万 QPS 系统可以"悠闲"地使用 300 秒甚至更长的 TTL；而千万 QPS 系统却陷入两难——长 TTL 导致故障切换迟缓，短 TTL 则引发客户端解析风暴。
这不是简单的参数调优问题，而是系统架构层面的本质差异。
一、TTL 的核心作用与基本权衡
DNS TTL 决定了客户端缓存 DNS 解析结果的有效期。在这个时间窗口内，客户端直接使用缓存的 IP 地址，无需重新解析。
TTL 设计的基本权衡：
| 维度 | 长 TTL（如 300s） | 短 TTL（如 30s） |
|---|---|---|
| 故障切换时间 | 最长等待 300s | 最长等待 30s |
| 客户端解析频率 | 低 | 高 |
| 首次连接延迟敏感度 | 低 | 高 |
| 灰度发布粒度 | 粗 | 细 |
对于百万 QPS 系统，这个权衡相对简单：选择较长的 TTL，牺牲一定的故障切换速度，换取系统的稳定性。但当流量规模跨越到千万 QPS 时，这个平衡被彻底打破。
二、百万 QPS：长 TTL 的"舒适区"
在百万 QPS 场景下，假设系统服务 100 万活跃用户，采用 300 秒的 TTL：
故障场景分析：
- 最坏情况下，故障切换需要等待 300 秒
- 300 秒内的流量损失 = 100 万 QPS × 300s = 3 亿次请求（理论最大值）
- 实际上，由于客户端缓存时间分布均匀，平均损失约为理论值的一半
对于百万级系统，这个损失通常在可接受范围内。更重要的是，业务往往有其他容错机制（如客户端重试、多机房部署）来缓解 DNS 切换延迟的影响。
长 TTL 的优势：
- 客户端解析压力可控：每个客户端平均每 300 秒解析一次
- 连接建立延迟稳定：绝大多数请求命中本地缓存
- 架构简单：无需额外的 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 解析延迟通常只有几十毫秒，但在千万级用户规模下，这会带来两个隐性成本：
- 首次连接延迟的"放大效应"
在短 TTL 策略下，更多请求会触发 DNS 解析。对于延迟敏感型业务（如实时通信、支付），这意味着更高比例的请求需要承担额外的解析延迟。
- 缓存过期的"时间窗口集中"问题
如果大量客户端在相近时间启动（如 App 推送后的打开高峰），它们的 DNS 缓存会在相近时间过期，形成解析请求的周期性波峰。
四、递归解析压力的数学模型
从客户端视角建立简化模型，分析不同 TTL 策略下的解析行为：
基础假设：
- 活跃用户数：N
- DNS 缓存 TTL：T 秒
- 单用户平均请求间隔：I 秒
客户端 DNS 解析频率估算：
当 I < T 时（用户活跃期间缓存有效）：
- 单用户解析频率 ≈ 1/T 次/秒
- 系统总解析频率 ≈ N/T 次/秒
具体数字对比：
| 场景 | 活跃用户 | TTL | 理论解析 QPS |
|---|---|---|---|
| 百万 QPS | 100 万 | 300s | ~3,300 |
| 千万 QPS（长 TTL） | 1000 万 | 300s | ~33,000 |
| 千万 QPS（短 TTL） | 1000 万 | 30s | ~330,000 |
可以看到，千万 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：
| 业务类型 | TTL 策略 | 说明 |
|---|---|---|
| 核心交易链路 | 30s + HTTPDNS | 快速切换优先 |
| 静态资源 CDN | 300s+ | 稳定性优先 |
| 内部服务调用 | 服务发现替代 DNS | 绑定长连接 |
六、本质差异总结
| 维度 | 百万 QPS | 千万 QPS |
|---|---|---|
| TTL 策略 | 长 TTL（分钟级） | 短 TTL（秒级）+ 智能缓存 |
| 故障切换容忍度 | 分钟级可接受 | 秒级要求 |
| DNS 架构 | 传统 DNS 即可 | HTTPDNS + 客户端智能缓存 |
| 连接策略 | 短连接为主可接受 | 必须高比例长连接复用 |
| 复杂度 | 配置级 | 架构级 |
核心结论：千万 QPS 不是百万 QPS 简单乘以 10。在 DNS TTL 这个维度上，它意味着从"配置参数调优"升级为"架构方案设计"，需要 HTTPDNS、智能缓存、长连接复用等多个子系统协同工作，才能在"快速故障切换"和"解析压力可控"之间取得平衡。
