指向同一个域的多个 A 记录似乎几乎专门用于实现 DNS 循环作为一种廉价的负载平衡技术。
针对 DNS RR 的常见警告是它不利于高可用性。当 1 个 IP 出现故障时，客户端将继续使用它几分钟。
通常建议使用负载均衡器作为更好的选择。
两种说法都不完全正确：
当流量为 HTTP 时，大多数 HTML 浏览器能够自动尝试下一个 A 记录，如果前一个记录关闭，则无需新的 DNS 查找。阅读此处第 3.1章和此处。
当涉及多个数据中心时，DNS RR 是在它们之间分配流量的唯一选择。
那么，对于多个数据中心和 HTTP 流量，使用 DNS RR 是否是确保在一个数据中心出现故障时立即进行故障转移的唯一方法？
谢谢，
华伦天奴
编辑：
- 当然，每个数据中心都有一个带有热备用的本地负载均衡器。
- 为即时故障转移牺牲会话亲和性是可以的。
- AFAIK DNS 建议数据中心而不是另一个数据中心的唯一方法是仅回复与该数据中心关联的 IP（或多个 IP）。如果数据中心变得不可访问，那么所有这些 IP 也是不可访问的。这意味着，即使智能 HTML 浏览器能够立即尝试另一个 A 记录，所有尝试都将失败，直到本地缓存条目过期并且完成新的 DNS 查找，获取新的工作 IP（我假设 DNS 自动建议一个失败时的新数据中心）。因此，“智能 DNS”不能保证即时故障转移。
- 相反，DNS 循环允许它。当一个数据中心出现故障时，智能 HTML 浏览器（大多数）会立即尝试将其他缓存的 A 记录跳转到另一个（工作）数据中心。因此，DNS 循环不能确保会话亲和性或最低 RTT，但似乎是当客户端是“智能”HTML 浏览器时确保即时故障转移的唯一方法。
编辑2：
- 有些人建议将 TCP Anycast 作为最终解决方案。在本文（第 6 章）中解释了 Anycast 故障转移与 BGP 收敛有关。为此，Anycast 可以使用 15 分钟到 20 秒来完成。在拓扑为此优化的网络上可能需要 20 秒。可能只有 CDN 运营商可以授予如此快速的故障转移。
编辑 3：*
- 我做了一些 DNS 查找和跟踪路由（也许一些专家可以仔细检查）并且：
- 唯一使用 TCP Anycast 的 CDN 似乎是 CacheFly，其他运营商如 CDN 网络和 BitGravity 使用 CacheFly。似乎它们的边缘不能用作反向代理。因此，它们不能用于授予即时故障转移。
- Akamai 和 LimeLight 似乎使用地理感知 DNS。但！他们返回多个 A 记录。从 traceroutes 看来，返回的 IP 位于同一个数据中心。因此，当一个数据中心出现故障时，他们如何提供 100% 的 SLA 让我感到困惑。