指向同一个域的多个 A 记录似乎几乎专门用于实现 DNS 循环，作为一种廉价的负载平衡技术。
对 DNS RR 的常见警告是它不利于高可用性。当 1 个 IP 出现故障时，客户端将继续使用它几分钟。
通常建议使用负载平衡器作为更好的选择。
这两种说法都不完全正确：
当流量为 HTTP 时，大多数 HTML 浏览器能够在前一个 A 记录关闭时自动尝试下一个 A 记录，而无需进行新的 DNS 查找。阅读这里是第 3.1 章和这里。
当涉及多个数据中心时，DNS RR 是在它们之间分配流量的唯一选择。
那么，在多个数据中心和 HTTP 流量的情况下，使用 DNS RR 是确保在一个数据中心发生故障时立即进行故障转移的唯一方法吗？
谢谢，
华伦天奴
编辑：
- 当然，每个数据中心都有一个带有热备用的本地负载均衡器。
- 为了实现即时故障转移而牺牲会话亲和性是可以的。
- 据我所知，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。
答案1
当我使用术语“DNS循环”时，我通常是指OP所描述的“廉价的负载平衡技术”。
但这并不是 DNS 用于实现全球高可用性的唯一方式。大多数时候，具有不同（技术）背景的人很难进行良好的沟通。
最好的负载平衡技术（如果钱不是问题的话）通常被认为是：
- 一个由“智能” DNS 服务器组成的 Anycast 全球网络，
- 以及一组遍布全球的数据中心，
- 每个 DNS 节点都实现水平分割 DNS，
- 并以某种方式将可用性和流量监控提供给“智能”DNS节点，
- 所以这样用户 DNS 请求通过 IP Anycast 流向最近的 DNS 服务器，
- 和这个DNS 服务器为最近/最佳数据中心通过“智能”分割水平 DNS 为该最终用户提供服务。
使用任播进行 DNS 通常没问题，因为 DNS 响应是无状态的，而且几乎非常短。因此，如果 BGP 路由发生变化，则不太可能中断 DNS 查询。
任播不太适合较长且有状态的 HTTP 对话，因此该系统使用水平分割 DNS。客户端和服务器之间的 HTTP 会话被保留在一个数据中心；它通常无法在不中断会话的情况下故障转移到另一个数据中心。
正如我在“A 记录集”中指出的那样，我称之为“DNS 循环”的设置可以与上述设置一起使用。它通常用于将流量负载分散到每个数据中心的多个高可用性负载平衡器上（以便您可以获得更好的冗余，使用更小/更便宜的负载平衡器，不会压垮单个主机服务器的 Unix 网络缓冲区等）。
那么，在多个数据中心和 HTTP 流量的情况下，使用 DNS RR 是确保高可用性的唯一方法吗？
不，如果“DNS 轮询”仅仅意味着为一个域分发多个 A 记录，那么事实并非如此。但巧妙使用 DNS 确实是任何全球高可用性系统的关键组成部分。以上说明了一种常见（通常也是最佳）方法。
编辑：谷歌论文“超越端到端路径信息来优化 CDN 性能”在我看来，它是实现最佳最终用户性能的全球负载分配方面最先进的技术。
编辑2：我读过这篇文章“为什么基于 DNS 的 GSLB 不起作用”楼主链接的，这是一个很好的概述——我建议你看一下。从头开始读。
在“浏览器缓存问题的解决方案”部分中，它提倡使用指向多个数据中心的多个 A 记录的 DNS 响应作为即时故障转移的唯一可能解决方案。
在底部附近的“淡化”部分，它扩展了显而易见的事实，即如果多个 A 记录指向多个大洲的数据中心，则发送多个 A 记录是不酷的，因为客户端将随机连接，因此经常会在另一个大洲获得“缓慢”的 DC。因此，为了使它真正发挥作用，需要在每个大洲建立多个数据中心。
这与我的步骤 1 - 6 不同。我无法就此提供完美的答案，我认为需要 Akamai 或 Google 等公司的 DNS 专家，因为这在很大程度上归结为实用技巧关于目前部署的 DNS 缓存和浏览器的限制。据我所知，我的步骤 1-6 是 Akamai 对其 DNS 所做的（有人可以证实这一点吗？）。
我曾经在移动浏览器门户网站（手机）担任过项目经理，我的感觉是，彻底破产浏览器的性能令人难以置信。我个人不相信需要最终用户终端“做正确的事情”的 HA 解决方案；因此我认为在不中断会话的情况下进行全局瞬时故障转移在今天是不可行的。
我认为上述步骤 1-6 是商品技术所能提供的最佳方案。此解决方案不具备即时故障转移功能。
我希望 Akamai、Google 等公司的 DNS 专家能来证明我错了。:-)
答案2
您的问题是：“DNS 循环调度是确保即时故障转移的唯一方法吗？”
答案是：“DNS 循环是绝不确保即时故障转移的正确方法”。
（至少不是单独存在）
实现即时故障转移的正确方法是使用 BGP4 路由，这样两个站点都使用相同的 IP 地址。使用这种方法，互联网的核心路由技术用于路线将请求发送到正确的数据中心，而不是使用互联网的核心寻址技术。
在最简单的配置中仅有的提供故障转移。它还可用于提供 Anycast，但需要注意的是，如果路由不稳定，基于 TCP 的协议将在切换时失败。
答案3
那么，在多个数据中心和 HTTP 流量的情况下，使用 DNS RR 是确保高可用性的唯一方法吗？
显然，这是一个错误的说法——你只需要看看 Google、Akamai、Yahoo，就会发现他们并没有使用循环[*] 响应作为唯一的解决方案（有些人可能会部分使用它，以及其他方法。）
有很多可能的选择，但实际上这取决于您对您的服务/应用程序还有哪些其他限制。
如果您还安排了 IP 地址的“故障转移”，则可以在简单的共置服务器方法上使用循环技术，而不必担心服务器故障。（但大多数人选择负载平衡技术、单个 IP 地址和负载平衡器之间的故障转移。）
也许您需要将单个会话的所有请求发送到相同的服务器，但您希望请求分布在不同的区域服务器集群中？对于这种情况，循环调度并不合适：您需要做一些事情来确保任何给定的客户端每次都访问相同的物理服务器集群（除非发生“异常”，例如服务器故障）。它们要么从 DNS 查询中收到一致的 IP 地址，要么路由到相同的物理服务器集群。解决方案包括各种商业和非商业 DNS“负载平衡器”，或者（如果您对网络有更好的控制）BGP 网络广告。您可以简单地安排您自己的域名服务器给出完全不同的响应（但是，由于 DNS 请求可以发送到各处，因此您无法通过这种方法实现任何位置亲和性。）
[* 我将使用“循环”，因为 DNS 术语中的“RR”表示“资源记录”。]
答案4
为什么 RFC 2782（与 MX/优先级一样适用于 http、imap 等服务）没有在任何浏览器中实现？事情会更简单... Mozilla 中有一个漏洞，已经存在十年了 !!! 因为这将是商业负载平衡器行业的终结 ??? 我对此非常失望。