我有一个redis集群（3个主集群和3个从集群）在kubernetes集群中运行。集群通过kubenetes服务（kube服务）公开。
我的应用服务器通过redis的java客户机连接到redis集群（使用kube服务作为uri）。我还在莴苣连接对象上设置了以下客户端选项：
ClusterTopologyRefreshOptions topologyRefreshOptions = ClusterTopologyRefreshOptions.builder()
.enablePeriodicRefresh(Duration.ofMinutes(10))
.enableAllAdaptiveRefreshTriggers()
.build();
ClusterClientOptions clusterClientOptions = ClusterClientOptions.builder()
.topologyRefreshOptions(topologyRefreshOptions)
.autoReconnect(true)
.disconnectedBehavior(ClientOptions.DisconnectedBehavior.REJECT_COMMANDS)
.build();
redisClient.setOptions(clusterClientOptions);现在，当我通过杀死一个redis主机（pod）来测试这个设置时，kubernetes通过重新安排一个新的pod来完成它的工作。但是新的pod有一个新的ip地址，它从来没有被莴苣发现过。莴苣如何处理再发现。上面的拓扑刷新逻辑似乎不会再次对新IP进行dns查找。
有没有样品或者有人处理过这个。我读过多篇关于莴苣本身的github问题，但都没有给出一个明确的方法来说明它是如何处理的。
最好的
1条答案
按热度按时间ugmeyewa1#
感谢您对上述问题的第一次评论。
所以我可以解决这个问题如下。
对于具有给定选项的客户机，上面的设置是很好的。然而，我不得不设置
disconnectedBehavior至ACCEPT_COMMANDS. 这确保了客户机在故障转移期间继续与redis进行操作。作为连续接受操作的结果，对于故障转移成功选择新主节点后到达客户端的第一次读或写，客户端将正确返回新节点的新ip地址。从那时起，客户机就知道故障节点所拥有的插槽的新ip是什么。
这是一种在下次尝试读写时进行协调的懒惰方法。但它是有效的，我相信它已经足够好了。我不确定是否有更好的方法来处理这个问题。