有没有一种方法可以使用Lettuce自动发现Redis群集中的新群集节点IP [英] Is there a way to auto discover new cluster node IP in Redis Cluster with Lettuce

问题描述

我有一个Redis集群 (3个主服务器和3个从属) 在 Kubernetes 集群中运行.集群通过 Kubenetes-Service(Kube-Service)公开.

I have a Redis Cluster (3 master and 3 slaves) running inside a Kubernetes cluster. The cluster is exposed via a Kubenetes-Service (Kube-Service).

我通过我的Redis的Lettuce Java客户端将应用程序服务器连接到Redis集群(使用 Kube-Service 作为URI).我还在Lettuce连接对象上设置了以下客户端选项:

I have my application server connected to the Redis Cluster (using the Kube-Service as the URI) via the Lettuce java client for Redis. I also have the following client options set on the Lettuce connection object:

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主服务器的(pods)之一来测试此设置时，Kubernetes通过重新安排新的Pod来完成其工作.但是新的Pod具有新的IP地址，Lettuce从未发现过.生菜如何处理重新发现.似乎上述用于拓扑刷新的逻辑不会为新IP再次执行DNS查找.

Now when I test this setup by killing one of my Redis master's (pods), Kubernetes does its job by re-scheduling a new pod. But the new pod has a new IP address and it is never discovered by Lettuce. How does Lettuce handle re-discovery. It seems like the logic above for topology refresh does not do a DNS lookup again for the new IPs.

那里是否有样品或已经处理过此样品的任何人.我读过有关莴苣本身的多个Github问题，但对于如何处理它并不清楚.

Is there any samples out there or anyone who have handled this. I have read multiple Github issues on Lettuce itself that doesn't give a clear way as to how it was handled.

最佳

推荐答案

对上述问题的第一条评论.

所以我能够按以下方法解决此问题.

So I was able to resolve this as follows.

• 使用给定选项的客户端的上述设置很好.但是，我必须将disconnectedBehavior设置为ACCEPT_COMMANDS.这样可以确保客户端在故障转移期间继续与Redis进行操作.
• 作为这种持续接受操作的结果，对于故障转移成功选出新的主服务器之后到达客户端的第一个READ或WRITE，客户端将正确返回新节点的新IP地址.从此以后，客户端将知道发生故障的节点所拥有的插槽的新IP.

• The above setup for the client with the given options is good. However, I had to set the disconnectedBehavior to ACCEPT_COMMANDS. This ensured that the client continues to engage with Redis for operations during the fail-over.
• As a result of this continuous accepting of operations, for the first READ or WRITE that arrives at the client after the failover had successfully elected a new master, the clister will correctly return the new IP address of the new node. From henceforth the client knows whats the new IP for the slots held by the failed node.

这是一种懒惰的方法，可在下次尝试读取或写入时进行协调.但这有效，我相信它已经足够了.我不确定是否有更好的方法来解决这个问题.

This is a lazy approach to reconcile on the next attempt to READ or WRITE. But it works and I believe it's good enough. I am not sure if there are better ways to handle this.

这篇关于有没有一种方法可以使用Lettuce自动发现Redis群集中的新群集节点IP的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！