When RedisCluster encountering Moved behavior

[yangbodong22011]

I noticed that the cluster documentation mentions that handling MOVED and ASK is transparent, that is, without configuring topologyRefreshOptions, it should be able to handle MOVED and ASK correctly, and refresh the topology.

But in io.lettuce.core.cluster.ClusterTopologyRefreshScheduler#onMovedRedirection, Enable is needed to refresh the topology:

    @Override
    public void onMovedRedirection() {

        if (isEnabled(ClusterTopologyRefreshOptions.RefreshTrigger.MOVED_REDIRECT)) {
            if (indicateTopologyRefreshSignal()) {
                emitAdaptiveRefreshScheduledEvent();
            }
        }
    }

and I noticed io.lettuce.core.cluster.ClusterTopologyRefreshOptions#DEFAULT_ADAPTIVE_REFRESH_TRIGGERS = Collections.emptySet(), the default is the empty set, which does not contain MOVED, that means that the cluster receives moved, and the topology will not be refreshed if topologyRefreshOptions is not configured.

my question is:

1. Is my above description accurate?
2. If it is accurate, then to use Cluster in Lettuce, topologyRefreshOptions must be configured, right? Otherwise, the topology cannot be updated after the cluster is scaled up or down.

[mp911de]

Moved redirections are followed transparently. However, without a topology refresh Lettuce would still send the command to the old master node to yield another redirect. In consequence, updating the topology would re-synchronize the cluster topology with the client and the client would send the next command directly to the current master to avoid redirects.

Configuring topology refreshes makes a lot of sense to minimize the number of redirects.

[yangbodong22011]

@mp911de Thanks for your reply, but since validateClusterNodeMembership is true by default, if topologyRefreshOptions is not configured, an error This partition is not known in the cluster view will be reported.

Therefore, I recommend calling Cluster nodes for topology refresh when the client first receives a Moved (adding Moved to DEFAULT_ADAPTIVE_REFRESH_TRIGGERS). As the Redis cluster specification suggests:

An alternative is to just refresh the whole client-side cluster layout using the CLUSTER SHARDS, or the deprecated CLUSTER SLOTS, command when a MOVED redirection is received. When a redirection is encountered, it is likely multiple slots were reconfigured rather than just one , so updating the client configuration as soon as possible is often the best strategy.

p.s. Jedis does the same: https://github.com/redis/jedis/blob/master/src/main/java/redis/clients/jedis/executors/ClusterCommandExecutor.java#L82

[mp911de]

In a scenario with heavy load, issuing topology updates on each redirect is very costly and that would reduce performance by 50%.

[yangbodong22011]

In a scenario with heavy load, issuing topology updates on each redirect is very costly and that would reduce performance by 50%.

Agree, but I think this is where redis itself needs to be optimized. For example, the cluster nodes command is cached in redis.

However, this should not be the cause of the failure caused by the user using lettuce to connect to the cluster.