我一直在使用生菜作为 Redis 客户端与 AWS Elasticache 交谈。我当前使用的特定配置是具有预定义节点地址的静态主/从。最近，主节点在启动故障转移过程时发生了翻滚，最终导致所有应用程序写入请求失败，并出现以下错误：
redis.RedisCommandExecutionException: READONLY You can't write against a read only slave.
从那时起，我一直在做一些研究，并意识到独立主/从可能是适合与Elasticache（在非集群模式下）通信目的的配置，因为根据AWS文档，客户端应始终仅与主终端节点通信 - 在故障转移事件中更新为指向新的主节点。
这让我不禁要问，为什么作者在使用AWS Elasticache时建议使用具有预定义节点地址的静态主/从方法？
有什么想法吗？
配置：1 个主节点和 2 个从节点
您的问题有两个答案，因为 AWS ElastiCache 可以以不同的方式使用：
AWS ElastiCache（非集群）具有自己的故障转移机制，在故障转移发生时不会通知您的应用程序。这取决于您的使用情况，这是好是坏：
如果要依赖故障转移，并且不想将副本用于其他读取，则仅使用主服务器即可。对于仅主节点使用，请将客户端指向主终结点。如果 ElastiCache 发生故障转移，则客户端连接将被重置。AWS 在后台更新主终端节点，客户端成功重新连接后，您将再次与（新）主节点通信。
唯一的拓扑源是 AWS ElastiCache 节点本身。生菜不会连接到 AWS 的 API（这永远不会发生）。Redis在本节中公开了连接的副本，但是：ElastiCache Redis节点报告无法访问的副本IP地址，因此无法通过拓扑发现连接到这些节点。INFO REPLICATION
虽然不可能从ElastiCache服务器推断出副本端点，但仍然可以提供静态端点。生菜连接到所有节点，并在启动时确定节点角色。这允许根据节点角色再次路由。如果发生故障转移（如您的情况），Lettuce 不会收到有关故障转移的通知，并坚持使用初始拓扑。
故障转移通知是缺少的位。虽然 Redis Sentinel 提供指示升级/角色更改的通知，但没有“仅”主/副本的机制。你可以说：好吧，让我们断开连接作为触发拓扑更新的信号。这在某些情况下可能有效，但在更多情况下（应用程序和Redis节点之间的网络分区，连接超时），它将在不需要的情况下触发更新。常规拓扑升级也只是尝试发现更改。
我对 AWS ElastiCache 的实施不满意。它适用于仅主数据库使用，但只要您想使用副本，就会依赖故障转移的专有实现。如果没有 AWS 故障转移（即在您自己的数据中心/Redis 设置中），一些运维人员会通知您 Redis 已关闭。它们将重新启动 Redis 节点或重新启动应用程序以还原操作。这些信号丢失。
与此同时，AWS 提供了 Redis Cluster，这可能是更好的 HA/故障转移设置，但 Redis Cluster 对应用程序有严格的限制。还可以在 AWS 的 ElastiCache API 上进行轮询，以从 API 方面发现拓扑，然后启动拓扑更新（重新连接）。
Lettuce 用于静态拓扑的主/副本 API 至少提供了一种使用副本的方法。其他一切都来自这种经历。欢迎任何形式的贡献（经验，建议，文档，代码）。
更新：根据 antirez/redis#5335 对齐复制副本措辞
