Keys in request don't hash to the same slot
Production Risk
Low. The server correctly prevents an invalid operation.
This error occurs in a Redis Cluster when a multi-key command (like MSET, SINTER, or a transaction) is issued with keys that do not all map to the same hash slot. Redis Cluster cannot atomically execute commands across different nodes.
- 1Calling a multi-key command with keys that are not related.
- 2Not using 'hash tags' to force related keys into the same slot.
- 3Attempting to run a MULTI/EXEC transaction involving keys that reside on different cluster nodes.
A client tries to set two keys, 'user:1000' and 'user:2000', in a single MSET command. They hash to different slots.
MSET user:1000 "a" user:2000 "b"
expected output
(error) CROSSSLOT Keys in request don't hash to the same slot
Fix 1
Use hash tags to force keys into the same slot
WHEN When keys need to be manipulated together atomically
MSET {user:1000}:name "Alice" {user:1000}:email "alice@example.com"Why this works
Redis Cluster only hashes the part of the key within curly braces `{}` to determine the slot. By using the same hash tag for related keys, you ensure they are stored on the same node.
Fix 2
Break the command into individual commands
WHEN When atomicity is not required
SET user:1000 "a" SET user:2000 "b"
Why this works
If the keys do not need to be modified atomically, simply send separate commands for each key. A cluster-aware client will route each command to the correct node.
✕ Try to create a huge hash tag for all keys in your application
This defeats the purpose of clustering, which is to distribute data and load. It will create a 'hot spot' where one node holds most of the data and receives most of the traffic, nullifying the benefits of the cluster.
Redis Cluster key distribution model
Content generated with AI assistance and reviewed for accuracy. Found an error? hello@errcodes.dev