多值轮询的能与不能
同一个域名配置多条同类型记录（多个 A 或 AAAA 地址）时，解析会在多个值之间轮询返回，实现轻量的横向分担。它的关键局限是没有任何健康判断：某个地址故障时仍可能被返回给部分用户，而这些用户的失败要等到本地缓存过期才可能变化。因此它适合辅助或临时场景，不适合承担核心流量。
基本信息
| 原理 | 同名多条 A 或 AAAA 记录轮询应答 |
|---|---|
| 优点 | 配置简单，不需要额外组件 |
| 局限 | 无健康检查，故障地址仍可能被返回 |
| 缓存影响 | 本地与递归缓存会让各客户端看到的顺序不同 |
| 生产建议 | 核心流量用云负载均衡收敛入口，解析层保持简单 |
典型使用场景
- 两台自有服务器做轻量分担，短期内没有引入负载均衡的计划
- 灰度验证：临时把部分解析指向新环境观察真实流量
- 多机房提供同样服务的非核心业务
- 客户端具备重试机制、能容忍单个地址失败时
- 作为正式负载均衡上线前的过渡方案
观察轮询效果
观察轮询效果
for i in $(seq 1 6); do dig +short app.example.com; done
# 连续查询观察返回顺序，注意本地与递归缓存会影响实际看到的顺序
dig +short app.example.com @8.8.8.8与负载均衡对比
| 能力 | 多值轮询 | 云负载均衡 |
|---|---|---|
| 健康检查 | 无 | 有，异常成员自动摘除 |
| 切换速度 | 受缓存影响 | 秒级到分钟级 |
| 分发粒度 | 按客户端与缓存随机 | 按权重与算法 |
| 运维成本 | 几乎为零 | 需要配置与规格管理 |
把解析轮询当负载均衡使用，故障期间会有部分用户持续失败，且失败比例随缓存分布而随机变化，很难定位。
轮询并不保证各地址流量均衡：客户端与递归缓存的分布会显著影响实际比例，统计时不要按等分预期判断。