如果当前大多数浏览器都坚持使用一个IP,那么DNS-RR就足以作为一个简单的故障转移解决方案.
解决方法
谷歌浏览器
谷歌浏览器(使用v58)将请求所有主机条目的地址(A,AAAA,CNAME)并将它们放入一个数组(address_list).然后Chrome将尝试按照从头到尾的顺序打开每个IP地址上的套接字,chrome不会尝试最快或最接近的IP,它假设第一个IP(由您的上游dns解析器给出)是最好的IP.在我的测试中,bind和windows dns服务器为每个查找提供不同的IP顺序,为每个IP提供看似50/50的带宽分配.此功能在chrome：// net-internals /#events& q = type中公开：SOCKET为：active
卷曲(libcurl / 7.54.0)
Curl也具有此故障转移功能,但–connect-timeout比chrome中的默认值长得多,chrome会立即故障转移,而Curl则不会.如果您使用libcurl并希望在一个IP失败的循环dns实例中存活(使用chrome但不在代码中),请确保将此值指定为更低.
DEFAULT_CONNECT_TIMEOUT:0让我觉得卷曲是不可能的.
* 149990ms连接时间后,继续！
在两个浏览器上,IP都不是粘性的,它们遵循DNS中给出的TTL,并且一旦ttl到期(chrome在内部维护,curl询问每个请求),每次执行ip选择如上所述.
这是什么意思？
DNS-RR适用于某些系统,但它不适用于故障转移.您应该期望来自DNS查找的所有结果都是(事实来源)有效且可用于提供流量.有许多方法可以确保IP可用性,例如虚拟浮动IP,BGP /路由技巧等.使用它们.
一旦有足够的基础设施可供测试,所有在仅IPv4环境中执行的测试将返回双栈结果.
我推测这些变化是IPv6-Fallback RFC Happy Eyeballs的副作用
更新一个有用的考虑因素,RR DNS只能协助负载平衡,而不是应用程序故障,如果您的一个节点有503,如果您的流量503s,您将提供40-60％.假设所列出的所有IP都是有效的工作端点(如果可达)
