How do you inspect which hash slots each Redis Cluster node owns, verify that two specific keys will be served by the same node, and how does a client library know where to send a command?

## The three views of cluster topology ### CLUSTER SHARDS (Redis 7.0 and later) The modern command. It returns one entry per shard: the slot ranges the shard owns, plus a list of its nodes with id, endpoint, port, role (master/replica), replication offset and health (`online`, `failed`, `loading`). Grouping by shard - rather than by slot range as the old command did - makes it natural to see a master together with its replicas, which is what most tooling actually wants. ### CLUSTER SLOTS (legacy) Returns an array of `[start, end, master, replica...]` tuples. It is deprecated in favour of `CLUSTER SHARDS` but still widely produced and consumed because older client libraries speak it. It carries no health field, which is precisely why it was superseded. ### CLUSTER NODES The raw text dump of the node's own view of the cluster: one line per node with `<id> <ip:port@busport> <flags> <master-id> <ping-sent> <pong-recv> <config-epoch> <link-state> <slot ranges>`. Two details make it the debugging tool of choice. First, flags show `myself`, `master`, `slave`, `fail?` (suspected) and `fail` (agreed). Second, slot entries can carry migration markers such as `[slot-><-nodeid]` (importing) and `[slot->-nodeid]` (migrating), which is how you see an in-flight slot move. Importantly, each of these commands reports **that node's belief** about the cluster. During a partition or a failover, different nodes can disagree transiently; if a diagnosis surprises you, ask a second node before concluding anything. ### CLUSTER INFO Summary counters: `cluster_state` (ok/fail), `cluster_slots_assigned`, `cluster_slots_ok`, `cluster_slots_pfail`, `cluster_slots_fail`, `cluster_known_nodes`, `cluster_size` (masters serving at least one slot), and epoch/stats fields. It is the fastest health probe to script. ## Verifying placement of specific keys `CLUSTER KEYSLOT <key>` asks the server to apply the exact rule - CRC16 over the key, or over the hash tag if present - and return the slot. Comparing the result for two keys is the authoritative co-location check; do not eyeball key names, because tag-parsing edge cases (empty `{}`, nested braces, a `}` before the `{`) are easy to get wrong. Watch shell quoting: unquoted braces may be mangled before they reach the server. Once you know the slot, `CLUSTER COUNTKEYSINSLOT <slot>` returns how many keys the queried node holds in it, and `CLUSTER GETKEYSINSLOT <slot> <count>` samples the actual names - invaluable when you are hunting the key family that made one slot enormous. Both must be run against the node that owns the slot. For cluster-wide sweeps, remember that `SCAN`, `KEYS`, `DBSIZE` and `INFO keyspace` are per-node: to survey the whole keyspace you iterate over every master. `redis-cli --cluster call <node> <command>` and `redis-cli --cluster info/check` automate the fan-out and also validate that all 16384 slots are covered exactly once. ## How a client library routes A cluster-aware ("smart") client works like this: 1. **Bootstrap.** Connect to any seed node and issue `CLUSTER SHARDS` (or `CLUSTER SLOTS`). Build an in-memory array of 16384 entries mapping slot to a connection pool for the owning master, plus its replicas. 2. **Route.** For each command, extract the key positions (from the command's arity metadata or a built-in table), compute `CRC16 mod 16384` locally applying hash-tag rules, and send the command straight to the owning master over a persistent connection. Because routing is local, a cluster command costs one round trip, just like standalone Redis - there is no proxy hop. 3. **Adapt.** If the slot map is stale, the contacted node replies with a redirect naming the correct node. The client follows it and schedules a map refresh. (The precise redirect semantics during migration are the resharding topic's material; what matters here is that the map is a *cache* and the server is the authority.) 4. **Multi-key and pipelines.** Since all keys of one command must share a slot, clients validate that up front; for pipelines they group commands per node and fan out, so a batch touching many slots becomes a handful of parallel round trips. 5. **Replica reads.** Optional and opt-in; the map already contains the replicas from the shard listing. ## Practical checklist - Health probe: `CLUSTER INFO` -> `cluster_state:ok` and `cluster_slots_assigned:16384`. - Ownership: `CLUSTER SHARDS`, cross-checked with `CLUSTER NODES` on a second node when something looks odd. - Placement: `CLUSTER KEYSLOT` per key; `COUNTKEYSINSLOT`/`GETKEYSINSLOT` to explain a fat slot. - Whole-cluster validation: `redis-cli --cluster check <host:port>`. - Remember every per-node command needs fan-out to be cluster-wide.