域名解析多 IP 就能做到高可用？

[MartinWu]

我刚刚做了个测试，测试环境如下：

服务器 A ，IP 192.168.0.3

服务器 B IP 192.168.0.4

两台服务器都启动了一个 http 服务，端口是 7891

然后，我在本地 hosts 文件添加了以下的信息

192.168.0.3  test.com
192.168.0.4  test.com

在这个环境下，我 curl test.com:7891 当然是能访问的。这时候基本上都是访问了 192.168.0.3:7891 了。

curl 的输出符合预期。

然后我现在把 A 的 http 服务关了，超出我预期的情况发生了。curl 依然能返回 http 服务的返回数据。

我 curl -v 看了下，出现了类似这样的信息：

Trying 192.168.0.3:7891...
* connect to 192.168.0.3 port 7891 failed: 拒绝连接*   
Trying 192.168.0.4:7891...
* Connected to test.com (192.168.0.4) port 7891 (#0)

这超出我的意料了。而后我也尝试了下最新版本的 chrome ，也有这样的特性。

这是一直以来所有的 http 客户端都有的特性吗？

[1423]

@MartinWu 可以去看 getaddrinfo 文档，建议也思考下 ipv6 浏览器如何使用。再了解下 happy eyeball 有哪些方案

[MartinWu]

@1423 这个是属于哪个规范的？

[MartinWu]

@1423 谢谢你，长见识了。

[bobryjosin]

这相当于把负载均衡交给 dns 了，客户端随机从解析值挑一个 ip ，只能作为分流手段，高可用不太现实，如果 dns 返回了一个已经挂掉的 ip ，dns 也没办法知道，除非你前置一个检测手段检测服务挂了自动更改 dns 解析，差不多可以实现基础高可用。

[Tumblr]

这个叫 DNS round-robin ，或者叫 DNS 轮询。
https://en.wikipedia.org/wiki/Round-robin_DNS

[flynaj]

这个是客户端功能，不是 DNS ，DNS 正常情况把一堆 IP 给客户端，你这个还只是简单的多 IPv4,目前客户端要处理的是 v6,v4 优先级.

[guyeu]

感觉这个特性还真能做到某种层面的高可用，比如我们曾有服务 IP 地址被运营商封掉，如果方式那个服务的域名绑定了两个 IP ，哪怕是同一个主机，也不会导致某省用户全面掉线＋我们花了整整一天排查这个问题

[gamexg]

chrome 、curl 自己实现的自动重试下一个连接。

不过为了支持 ipv6 ，应该不少软件都会有类似的实现了。
ipv6 一般都是一个协议短期未成功则立刻同步另一个协议尝试。
顺便加上同协议多个 ip 地址并不麻烦。

另外 go 标准库我记得也是实现了单 ip 失败自动切换到另一个 ip 尝试。

[MartinWu]

@gamexg 因为我记得以前是没有这个特性的。看到 chrome 和 curl 都实现了，我猜应该是某个时候开始出现的一个共识，然后楼上就提到了 happy eyeball 。应该就是当时为了解决 ipv4 和 ipv6 并存的问题而被提出的，然后逐渐大家都这么干了。

[DefoliationM]

不能，因为要看客户端实现，可能客户端就是随机选择其中一个