我正在测试由Redis支持的ElastiCache，其规格如下：
- 使用 Redis 2.8，带多可用区
- 单个复制组
- US-east-1b 中的 1 个主节点，US-east-1c 中的 1 个从节点，US-east-1d 中的 1 个从节点
- 应用程序写入部分直接使用主节点的端点 (primary-node.use1.cache.amazonaws.com(
- 应用程序仅执行读取的部分指向 HAProxy 中配置的自定义端点 (readonly.redis.mydomain.com(，然后指向另外两个读取从端点。(readslave1.use1.cache.amazonaws.com 和 readslave2.use1.cache.amazonaws.com(
现在假设主节点(主节点(在 us-east-1b 中出现故障。
据我了解，如果主实例失败，我不必更改写入 Redis (primary-node.use1.cache.amazonaws.com( 的端点的 url，尽管从那里我仍然有以下问题：
- 我是否必须更改只读从属服务器的端点名称？
- 失踪的奴隶多久才能被添加到池中？
如果还有什么我缺少的，我将不胜感激。
谢谢！
如果您使用的是 ElastiCache，则应使用 AWS 提供的"主终端节点"。
该终端节点实际上由 Route53 支持，如果主(主(Redis 关闭，因为您启用了 MutliA-Z，它将自动故障转移到其中一个只读副本(从属(。在这种情况下，您无需修改 redis 的终端节点。
我不知道你为什么有这样的设计，似乎你只想写到主人，但总是从奴隶那里读。对于 HA 代理部分，您应该使用其"读取端点"对所有 3 个 redis 节点进行 TCP 检查在 haproxy 中，您可以检查端点是否为 SLAVE，如果是，您的 haproxy 应将流量重定向到该端点。
请注意，在应用层中，如果您的 redis 驱动程序不支持自动重新连接，您的脚本将无法连接到新的主节点。
除了"自动重新连接"之外，由于AWS正在使用Route53 DNS进行故障转移，因此某些库不会再次执行NS查找，这意味着DNS仍然指向旧主节点的旧IP。
使用HAproxy可以解决这个问题。