UPDATE - 2023 - Verx Redis now supports scan but there's a bug see https://github.com/vert-x3/vertx-redis-client/issues/345
My team has been using the Vertx Redis client for some time and using the keys command with a Redis cluster and I was asked to refactor to use the scan command instead since "keys" isn't meant for production.
When I went to use scan I got an error from the client saying "scan not supported - use non cluster client on the right node." So it appears that the Vertx Redis client supports cluster-wide "keys" but not "scan." I learned that I'm supposed to create 1 client per node if I want to do a cluster-wide "scan" e.g. something like this but that seems like an overfly complex and poorly performant choice (or I can use "hash tags" which won't work for my use case).
I'm trying to figure out which commands are supported cluster-wide and which aren't (so we don't make another mistake like this ) and the only hint I see is in the Redis cluster spec:
Redis Cluster implements all the single key commands available in the non-distributed version of Redis.
My question is - what is a single key command?
Or another explanation I saw here was the following:
The only different between distributed and non-distributed Redis clients is that in the distributed case MOVED and ASKS will be "followed."
I'm also not clear on how a MOVED or ASK is followed - I assume it just means that the client reconnect to the correct node and tries again? That seems horribly non-performant as discussed here.
It's also odd that the Vertx client documentation doesn't mention this or the more popular Jedis client.
Am I missing some key documentation that explains all this?
My question is - what is a single key command?
It's a command, which has a single key a as parameter. For example, SET key value, only sets a single key.
In fact, you missed the second sentence: Commands performing complex multi-key operations ... are implemented for cases where all of the keys ... hash to the same slot. So if k1, k2 and k3 are located on the same hash slot, you can send MGET k1 k2 k3 command to Redis Cluster.
I assume it just means that the client reconnect to the correct node and tries again?
YES.
That seems horribly non-performant as discussed here.
A decent Redis client should cache the slot-node mapping. So if the slot-node mapping has not changed, clients can calculate the right slot/node based on key, and send the command to the right node. So that it can avoid the redirection.