通常,像Amazon的Elastic Load Balancers这样的负载均衡器使用具有多个A记录的DNS记录集来提供多个负载均衡器实例,这些实例可以处理到请求端点的流量：
$dig +short my-fancy-elb.us-east-1.elb.amazonaws.com 10.0.1.1 10.0.1.2
如果我尝试在详细模式下卷曲此URL,我注意到curl似乎循环尝试两个IP地址：
$curl -ivs http://my-fancy-elb.us-east-1.elb.amazonaws.com | grep -i 'connected' * Connected to my-fancy-elb.us-east-1.elb.amazonaws.com (10.0.1.1) $curl -ivs http://my-fancy-elb.us-east-1.elb.amazonaws.com | grep -i 'connected' * Connected to my-fancy-elb.us-east-1.elb.amazonaws.com (10.0.1.2)
事实是curl对由curl二进制文件本身完成的记录集中描述的A记录进行了循环,还是Linux内核为它做了什么？
TCP存在于第4层,DNS存在于第7层,因此我认为各个二进制文件和库必须实现自己的负载平衡和故障转移：获取给定域名的DNS记录集并选择TCP地址从该集连接到.
我可以合理地期望像curl这样的编程语言,浏览器和库能为我做A记录的负载平衡和故障转移吗？
解决方法
简短的回答是它有所不同.
当答案集中存在多个地址记录时,查询的DNS服务器通常以随机顺序返回它们.操作系统通常会按照收到的顺序将返回的记录集呈现给应用程序.也就是说,事务的两端都有选项(名称服务器和操作系统)可能会导致不同的行为.通常不使用这些.例如,一个名为/etc/gai.conf的鲜为人知的文件在基于glibc的系统上控制它.
Zytrax书籍(Rocket Scientists的DNS)有a good summary on the history of this topic,并得出结论,RFC 6724是应用程序和解析器实现应遵循的当前标准.
从这里开始,值得注意的是RFC 6724中的choice quote：
Well-behaved applications SHOULD NOT simply use the first address returned from an API such as getaddrinfo() and then give up if it fails. For many applications,it is appropriate to iterate through the list of addresses returned from getaddrinfo() until a working address is found. For other applications,it might be appropriate to try multiple addresses in parallel (e.g.,with some small delay in between) and use the first one to succeed.
该标准鼓励应用程序在失败时不在第一个地址停止,但它既不是要求,也不是许多随便编写的应用程序要实现的行为.除非您确定消费应用程序中较大(或至少最重要)的百分比可以很好地发挥作用,否则您不应该仅依赖多个地址记录来实现高可用性.现代浏览器往往对此很好,但请记住,它们并不是您正在处理的唯一消费者.
(另外,正如@kasperd在下面所说,重要的是区分HA在购买HA和负载均衡方面的价格)
