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