AWS Route53 故障转移和 chrome DNS 缓存

Question

我使用 Route53 进行了非常标准的故障转移：

• 两个地区
• 主要，与运行状况检查相关联，以及每个区域的辅助故障转移记录。
• 记录指向 API。此外，我们还有使用 API 的前端 JS 应用程序。

如果 Primary 运行状况不佳，则 DNS 会返回一条 Secondary 记录，如果用户在失败时未使用该应用程序，则该记录运行良好。

所以：

• 如果 Primary 运行状况不佳，并且用户在故障转移激活后尝试使用该应用 - 一切正常（指向 Secondary 记录）

• 如果用户在使用应用程序时主记录变得不健康，应用程序会尝试访问不可用的旧 IP 地址，因此不会切换到辅助记录。 p>

似乎 DNS 已缓存（可以在此处检查 chrome://net-internals/#dns for Chrome）。用户可以在一段时间不活动后继续使用该应用：当 API 未触发且 Chrome 的 DNS 缓存已过期时。

当用户使用应用程序时主节点变得不健康时，是否有针对这种特殊情况的解决方法？或者在这种情况下我们如何让用户体验更愉快？

添加示例：

• 用户 1 正在使用应用程序（应用程序是 Ember.js 应用程序）
• 主服务器已关闭，故障转移已激活
• 之后用户 2 访问应用程序（故障转移处于活动状态）并且 route53 提供了辅助记录，因此一切正常。
• 同时，用户 1 仍在尝试访问应用程序，应用程序向 API 发出请求。但是一个应用正在从 chrome DNS 缓存中访问旧 IP。

添加：

我们正在使用别名记录（Route53 上 A 记录的 TTL 始终为 60 秒）

Answer 1

这一切都归结为 TTL。如果您将资源上的 TTL 设置为 30 秒，则浏览器应每 30 秒解析一次地址，以便在大多数情况下可以接受。当然，这是以一些延迟和更多成本为代价的（尽管 R53 真的很便宜）。如果您需要更短的 TTL you can set it up。

如果您想对其进行更多控制，则必须设置自己的负载均衡器，当您的机器出现故障时，该负载均衡器将路由到不同的区域，但在 EC2 发生故障时不会为您节省时间（可能会为您争取足够的时间启动一个新实例）。