Java AWS Elasticache的Redis客户端主/从配置

我一直使用莴苣作为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（非集群）具有自己的故障切换机制，在发生故障切换时不会通知应用程序。这取决于你的用途，这是好是坏：

仅限Master使用 如果您希望依赖故障切换，并且不希望将副本用于其他读取，那么只能使用主副本。对于仅主端点使用，您可以将客户端指向主端点。如果ElastiCache发生故障转移，则会重置客户端连接。AWS会在后台更新主端点，一旦客户端成功重新连接，您就可以再次与（新的）主节点通话

为什么在这种情况下不可能使用副本？ 唯一的拓扑源是AWS ElastiCache节点本身。莴苣不会连接到AWS的API（这永远不会发生）。Redis在

信息复制

部分中公开连接的副本，但是：ElastiCache Redis节点报告无法访问的副本IP地址，因此无法通过拓扑发现连接到这些节点

使用主副本和副本 尽管无法从ElastiCache服务器推断副本端点，但仍然可以提供静态端点。莴苣连接到所有节点，并在启动时确定节点角色。这允许再次根据节点角色进行路由。如果发生故障转移（如您的情况），莴苣不会收到故障转移的通知，而是坚持使用初始拓扑

故障转移通知 故障转移通知是缺少的位。虽然Redis Sentinel提供指示升级/角色更改的通知，但没有“仅”主/副本的机制。您可以说：好的，让我们断开连接作为触发拓扑更新的信号。这在某些情况下可能有效，但在更多情况下（应用程序和Redis节点之间的网络分区、连接超时），它将触发更新，而无需进行更新。常规拓扑升级也只是尝试发现更改

第三个答案 我对AWS ElastiCache的实现不满意。它只适用于主机使用，但只要您想使用副本，就需要依赖专用的故障切换实现。如果没有AWS故障切换（即在您自己的数据中心/Redis设置中），您将收到一些Ops人员通知，Redis已关闭。他们要么重新启动Redis节点，要么重新启动应用程序以恢复操作。这些信号丢失了

同时，AWS提供了Redis Cluster，这可能是更好的HA/故障切换设置，但Redis Cluster对应用程序具有严重限制。也可以在AWS的ElastiCache API上进行轮询，从API方面发现拓扑，然后启动拓扑更新（重新连接）

莴苣用于静态拓扑的主/副本API至少提供了一种使用副本的方法。其他一切都源于这种经历。欢迎任何形式的贡献（经验、建议、文档、代码）

---

更新：根据您的实际配置调整副本措辞？一主一从？哨兵？感谢您的详细回复！在使用独立主模式之后，我最终意识到了无法访问的从属（IP是私有的）的问题。因此，基本上，这取决于我们是否需要AWS的自动故障切换。在主/从模式下，我认为很可能会希望使用该功能，但随后必须放弃读从模式。尽管有您提到的案例，我还是倾向于使用故障转移通知方法。如果可以作为ClientOption使用（默认情况下可以禁用），IMO值得额外的开销，并且更适合Elasticache用户。此外，这是一个很棒的writeup，值得添加到wiki中。