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