Why use CLUSTER NODES rather than CLUSTER SLOTS?

[jake-at-work]

Why does lettuce.io use CLUSTER NODES command for cluster topology rather than CLUSTER SLOTS? The documentation for CLUSTER NODES says the clients should use CLUSTER SLOTS. CLUSTER NODES is more administrative debug information and requires considerable parsing magic. CLUSTER SLOTS replies with a nested array of slot range to nodes mapping.

[mp911de]

There are multiple reasons. CLUSTER NODES provides all topological details including flags to determine node roles and it maps better to the actual client architecture. CLUSTER SLOTS is fine for routing purposes. It has two main drawbacks:

1. It doesn't report the full topology
2. Nodes without assigned slots are not reported

The client works in a way that we keep connections per node within the cluster. Routing a command consists of mapping the key into a slot and then checking which nodes can handle a particular request. The topology also allows for verifying redirects in the sense that we can check whether the target node is part of the cluster or whether a Redis redirect targets towards an unknown node.

Nodes without assigned slots are good candidates for Pub/Sub operations as Pub/Sub isn't tied to the keyspace.

Finally, CLUSTER NODES allows reasoning about the topology which is required for testing when we want to hit a certain node. We can resolve a Redis node by either its ID or host/port. The ID-based host resolution wouldn't work with using solely CLUSTER SLOTS.

[jake-at-work]

Thanks for the detailed response. That really helps us, Apache Geode, understand how to fit into Redis client. From what we are seeing some clients are using CLUSTER SLOTS and others CLUSTER NODES so understanding the reasons some clients are choosing one over the other helps greatly.

I can understand using CLUSTER NODES to get a sense of all the nodes in the cluster but it has one major drawback in slot assignment that CLUSTER SLOTS does not. The CLUSTER SLOTS response is capable of returning slot arrangements that don't fit the Redis standard model of 1 primary and X replicas of said primary. Since CLUSTER SLOTS looks at the world from the perspective of the slot one could have a situation where slot 1 is primary on node A and replicated on B, and slot 2 is primary on A and replicated on C. This arrangement can't be described in the CLUSTER NODES response. Again I realize this is not typical for Redis proper but is is possible for other distributed data stores, like Geode. Having that flexibility in slot topology provided by CLUSTER SLOTS allows those alternative arrangements to be possible.

It strikes me that a hybrid approach may be more effective at solving both issues. Fetch the overall member set from CLUSTER NODES ignoring the slot placement info and get the slot placement via CLUSTER SLOTS.

Finally, CLUSTER NODES allows reasoning about the topology which is required for testing when we want to hit a certain node. We can resolve a Redis node by either its ID or host/port. The ID-based host resolution wouldn't work with using solely CLUSTER SLOTS.

Is the issue here that CLUSTER SLOTS may not give you all the nodes if they didn't have slot assignments because this command does provide the node ID.