Sharding with Hash Slots
Redis Cluster splits the entire keyspace into 16384 fixed hash slots. Every key is mapped to a slot using CRC16(key) mod 16384, and each slot is owned by exactly one primary node in the cluster at any time. Unlike consistent hashing schemes, the slot count is fixed regardless of cluster size, and resharding means moving whole slots (and the keys in them) between nodes, not recomputing a hash ring. A cluster with three primaries might own slots 0-5460, 5461-10922, and 10923-16383 respectively, and any client can be redirected via a MOVED response to the node that actually owns the slot for a given key.
Cricket analogy: It's like a league dividing every team alphabetically into three fixed groups for scheduling — regardless of how many total teams join, matches are always assigned to whichever group's fixture table currently owns that slot.
Resharding and Redirection
When you add or remove a node, an operator (or redis-cli --cluster reshard) migrates specific slots from one node to another, moving the keys within them using an atomic MIGRATE-based process. During migration a slot can be marked MIGRATING on the source and IMPORTING on the destination; if a client asks the source for a key that's already moved, it gets an ASK redirect to the destination for that one operation, while MOVED indicates a permanent ownership change the client should cache. Cluster-aware client libraries maintain a local slot-to-node map and follow these redirects, refreshing their map on MOVED.
Cricket analogy: It's like a match being moved to a different stadium mid-tournament — ticket holders who show up at the old venue get redirected once (ASK) for that game, but the schedule updates permanently (MOVED) for all future fixtures.
Creating and Querying a Cluster
# Create a 3-primary, 3-replica cluster (6 nodes)
redis-cli --cluster create \
10.0.0.1:6379 10.0.0.2:6379 10.0.0.3:6379 \
10.0.0.4:6379 10.0.0.5:6379 10.0.0.6:6379 \
--cluster-replicas 1
# Check which slot a key maps to
redis-cli -c -h 10.0.0.1 CLUSTER KEYSLOT user:1001
# (integer) 3844
# Connect with -c to follow MOVED/ASK redirects automatically
redis-cli -c -h 10.0.0.1 GET user:1001
# -> Redirected to 10.0.0.2:6379
# "active"Multi-Key Operations and Hash Tags
Because keys can live on different nodes, multi-key operations like MSET or transactions across arbitrary keys aren't guaranteed to work unless all involved keys hash to the same slot. Redis Cluster supports hash tags: if a key contains a substring in curly braces, only that substring is hashed to determine the slot, e.g. user:{1001}:profile and user:{1001}:orders both map to the same slot because {1001} is hashed instead of the whole key. This lets you deliberately co-locate related keys so you can use MGET, MULTI/EXEC, or Lua scripts across them safely within a cluster.
Cricket analogy: It's like ensuring a batter's strike rate and average are always filed in the same team's records folder by tagging both with the player's ID, even though other stats might be filed elsewhere by match.
Without hash tags, a multi-key command spanning slots on different nodes fails with a CROSSSLOT error. Design your key schema with hash tags upfront for any keys you'll need to touch together (transactions, Lua scripts, MGET) — retrofitting this after data is already spread across the cluster requires a resharding migration.
Redis Cluster requires a minimum of three primary nodes to form a valid cluster and reach consensus on slot ownership; each primary should have at least one replica for automatic failover, which Cluster handles natively without needing separate Sentinel processes.
- Redis Cluster partitions the keyspace into 16384 fixed hash slots, each owned by one primary node.
- Keys map to slots via CRC16(key) mod 16384; resharding moves whole slots between nodes.
- MOVED indicates a permanent slot ownership change; ASK indicates a one-time redirect during migration.
- Cluster-aware clients cache the slot map and follow MOVED to avoid repeated redirects.
- Multi-key operations require all keys to share a slot, enforced via hash tags like {user_id}.
- CROSSSLOT errors occur when a multi-key command spans nodes without matching hash tags.
- A minimum of three primaries is required, and Cluster handles failover natively without Sentinel.
Practice what you learned
1. How many hash slots does Redis Cluster divide the keyspace into?
2. What is the difference between a MOVED and an ASK redirect?
3. How do hash tags like user:{1001}:profile affect slot assignment?
4. What causes a CROSSSLOT error in Redis Cluster?
5. What is the minimum number of primary nodes required to form a valid Redis Cluster?
Was this page helpful?
You May Also Like
Redis Replication
How Redis copies data from a primary to one or more replicas for read scaling and failover readiness, and the consistency tradeoffs that come with it.
Redis Sentinel for High Availability
How Redis Sentinel monitors a primary/replica deployment, detects failures, and orchestrates automatic failover without a cluster topology.
Redis Persistence Tradeoffs
A practical comparison of RDB snapshots and AOF logging in Redis, and how to choose or combine them based on your durability and performance needs.