在亚马逊失败并阅读了许多关于冗余/分布式在实践中意味着什么的文章之后，DNS 似乎是弱点。例如，如果 DNS 设置为数据中心之间的循环，并且其中一个数据中心发生故障，那么似乎许多浏览器都会缓存该 DNS 并继续命中故障节点。
我了解生存时间 (TTL)，但当然这可能会设置为很长的时间。
所以我的问题是，如果浏览器没有收到来自 IP 的响应，是否足够聪明地刷新 DNS 以希望被路由到另一个节点？
【问题讨论】：
标签： dns redundancy
循环 DNS 是每个浏览器的事情。 This is how mozilla does it:
单个主机名可以解析为多个 IP 地址，每个 IP 地址都存储在 成功查找后返回的主机实体。 Netlib 保留 dns 的顺序 服务器返回 IP 地址。如果在连接期间的任何时候，IP 地址 当前正在使用的主机名失败，netlib 将使用存储在下一个 ip 地址 主机实体。如果那个失败，则查询下一个，依此类推。这种进展通过 可用的 IP 地址在 NET_FinishConnect() 函数中完成。在 URL 加载之前 被认为是完整的，因为它的连接出错，它的主机实体被咨询 确定是否应该为给定主机尝试另一个 IP 地址。一次ip 地址失败，它已经出局，从缓存中的主机实体中删除。如果所有 IP 地址都在 主机实体失败，netlib 传播“服务器未响应”错误备份调用 链。
至于亚马逊的失败，在亚马逊停机期间 DNS 没有任何问题。 DNS 服务器正确报告了 IP 地址，并且浏览器使用了这些 IP 地址。搞砸了在亚马逊这边。他们将流量重新路由到不堪重负的集群。 DNS 已死机，但集群本身无法处理巨大的流量负载。
EC2 提供了两个非常重要的可用性构建块：区域和可用性 区域。按照设计，区域是我们基础设施的完全独立部署。 区域彼此完全隔离，并提供最高程度的 独立。许多用户利用多个 EC2 区域来实现极高水平的 容错性。但是，如果要在区域之间移动数据，则需要通过 您的应用程序，因为我们不会代表我们的用户在区域之间复制任何数据。
换句话说，“还记得我们告诉你我们拥有的所有高可用性吗？是的，这仍然取决于你。”由于他们自己的笨拙，他们将集群中的主节点和辅助节点都取出了，并且没有任何东西可以进行故障转移。然后当他们把它全部带回来时，突然出现了“重新镜像风暴”，因为节点试图同时同步，导致更多的拒绝服务。 DNS 与它无关。
【讨论】：