AWS Elasticache 的 Redis 客户端 Lettuce Master/Slave 配置
Redis client Lettuce Master/Slave configuration for AWS Elasticache
我一直在使用 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 连接到所有节点并在 startup 上确定节点角色。这允许再次根据节点角色进行路由。如果发生故障转移（如您的情况），Lettuce 不会收到有关故障转移的通知并坚持使用初始拓扑。
故障转移通知
故障转移通知是缺失的部分。虽然 Redis Sentinel 提供指示 promotion/role 更改的通知，但没有 'just' Master/Replica 的机制。您可以说：好的，让我们断开连接作为触发拓扑更新的信号。这在某些情况下可能有效，但在更多情况下（应用程序和 Redis 节点之间的网络分区、连接超时）它会在不需要的情况下触发更新。定期拓扑升级也只是尝试发现变化。
第三个答案
我对 AWS ElastiCache 实施不满意。它仅适用于主服务器，但一旦你想使用副本，你就依赖于故障转移的专有实现。如果没有 AWS 故障转移（即在您自己的数据 center/Redis 设置中），一些运维人员会通知您 Redis 已关闭。他们要么重启 Redis 节点，要么重启应用程序以恢复操作。这些信号丢失了。
与此同时，AWS 提供了 Redis Cluster，这可能是更好的 HA/failover 设置，但 Redis Cluster 对应用程序有严格的限制。也可以在 AWS 的 ElastiCache API 上进行轮询以从事物的 API 端发现拓扑，然后启动拓扑更新（重新连接）。
Lettuce 的 Master/Replica API 用于静态拓扑的用途是至少提供一种处理副本的方法。其他一切都源于这种体验。欢迎以任何形式（经验、建议、文档、代码）做出贡献。
更新：根据antirez/redis#5335
对齐副本措辞
我一直在使用 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 连接到所有节点并在 startup 上确定节点角色。这允许再次根据节点角色进行路由。如果发生故障转移（如您的情况），Lettuce 不会收到有关故障转移的通知并坚持使用初始拓扑。
故障转移通知
故障转移通知是缺失的部分。虽然 Redis Sentinel 提供指示 promotion/role 更改的通知，但没有 'just' Master/Replica 的机制。您可以说：好的，让我们断开连接作为触发拓扑更新的信号。这在某些情况下可能有效，但在更多情况下（应用程序和 Redis 节点之间的网络分区、连接超时）它会在不需要的情况下触发更新。定期拓扑升级也只是尝试发现变化。
第三个答案
我对 AWS ElastiCache 实施不满意。它仅适用于主服务器，但一旦你想使用副本，你就依赖于故障转移的专有实现。如果没有 AWS 故障转移（即在您自己的数据 center/Redis 设置中），一些运维人员会通知您 Redis 已关闭。他们要么重启 Redis 节点，要么重启应用程序以恢复操作。这些信号丢失了。
与此同时，AWS 提供了 Redis Cluster，这可能是更好的 HA/failover 设置，但 Redis Cluster 对应用程序有严格的限制。也可以在 AWS 的 ElastiCache API 上进行轮询以从事物的 API 端发现拓扑，然后启动拓扑更新（重新连接）。
Lettuce 的 Master/Replica API 用于静态拓扑的用途是至少提供一种处理副本的方法。其他一切都源于这种体验。欢迎以任何形式（经验、建议、文档、代码）做出贡献。
更新：根据antirez/redis#5335
对齐副本措辞