A tag that works
Two keys sharing a hash tag land in the same slot, which is what makes a multi-key command over them legal
{user1000}:profile
{user1000}:sessions
{user1000}:cartPaste keys and get the slot Redis Cluster will route each one to. The slot is CRC16 of the key masked to 16,384, and a hash tag narrows what gets hashed, which is the whole mechanism behind co-locating keys.
Only used for the node column. An even split is a guess: the real ranges come from CLUSTER NODES, and after any resharding they will not be even.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Hash. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
Two keys sharing a hash tag land in the same slot, which is what makes a multi-key command over them legal
{user1000}:profile
{user1000}:sessions
{user1000}:cartEmpty braces are not a tag, so the whole key is hashed and the co-location the author expected does not happen
{}user:1000:profile
{}user:1000:sessionsKeys that look related are spread across slots, so MGET over them is rejected
user:1000:profile user:1000:sessions user:1000:cart
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Empty braces are not a tag. Redis hashes the whole key including the braces, so keys the author believes are co-located are spread across slots.
Instead:A tag needs at least one byte between the braces. `{user1000}:profile`, never `{}user1000:profile`.
Slots are the unit of assignment, not of work. A tag used by a large tenant puts all of that tenant's keys in one slot, and no rebalance can separate them.
Instead:Choose the tag so it partitions the data, usually per user or per tenant, not per batch or per job.
Slot-to-node assignment lives in the cluster and changes with every resharding. Nothing computed in a browser can know it.
Instead:Use CLUSTER NODES or CLUSTER SLOTS for the actual mapping. The node column here only illustrates distribution.
Redis Cluster does not hash keys to nodes. It hashes them to one of 16,384 slots, and slots are assigned to nodes. That indirection is what makes resharding possible without rehashing every key, and it is why co-location has to be expressed in the key name itself.
HASH_SLOT = CRC16(key) mod 16384, using the XMODEM variant: polynomial 0x1021, initial value zero, no reflection and no final XOR. There is no seed, no per-cluster salt and no configuration. The same key gives the same slot on every Redis Cluster that has ever existed, which is why this can be computed here with no server.
If a key contains a { followed later by a }, with at least one byte between them, Redis hashes ONLY what is between them. {user1000}:profile and {user1000}:sessions both hash user1000, so both land in the same slot and a multi-key command over them is legal. Without the braces they are two unrelated keys in two unrelated slots.
It is the FIRST { and then the FIRST } after it, so {a}{b} hashes a and nothing else. Empty braces are not a tag, so {}foo hashes the whole key including the braces. A { with no } after it is not a tag either. In all three cases Redis reports no error and the key is simply distributed as though the braces were ordinary characters, which is the failure this page exists to make visible.
The CRC is computed over the UTF-8 bytes of the key, not its characters. A key containing any non-ASCII character hashes differently than a naive implementation that walks JavaScript string indices would suggest, and a client that gets this wrong routes to the wrong node.
It cannot tell you which node owns a slot. Slot-to-node assignment lives in the cluster and changes with every resharding, so the node column here assumes an even split purely to illustrate distribution. For the real mapping, use CLUSTER NODES or CLUSTER SLOTS against your cluster. It also cannot know whether your cluster is running in cluster mode at all: on a standalone Redis, slots are not used and every key is local.