Multi-key operations in cluster in Redis - Step-by-Step Execution

Concept Flow - Multi-key operations in cluster

Client sends multi-key command

↓

Cluster identifies keys' hash slots

↓

Are all keys in same slot?

No→Error or Redirect

Yes↓

Command executed on node owning slot

↓

Result returned to client

The cluster checks if all keys belong to the same hash slot. If yes, it executes the command on that node; otherwise, it returns an error or redirect.

Execution Sample

Redis

MSET key1 value1 key2 value2
GET key1
GET key2

Set two keys and get their values in a Redis cluster, ensuring keys are in the same hash slot.

Execution Table

Step	Action	Keys involved	Hash Slots	Result	Notes
1	Client sends MSET command	key1, key2	slot 1234, slot 1234	Command accepted	Both keys hash to same slot
2	Cluster routes MSET to node owning slot 1234	key1, key2	slot 1234	Values set	Atomic multi-key set succeeds
3	Client sends GET key1	key1	slot 1234	value1	Single key get succeeds
4	Client sends GET key2	key2	slot 1234	value2	Single key get succeeds
5	Client sends MGET key1 key3	key1, key3	slot 1234, slot 5678	Error or Redirect	Keys in different slots, multi-key command fails

💡 Multi-key commands require all keys in the same hash slot; otherwise, cluster returns error or redirect.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5
key1	null	pending set	value1	value1	value1	value1
key2	null	pending set	value2	value2	value2	value2
key3	null	null	null	null	null	null

Key Moments - 2 Insights

Why does the MGET command with keys in different slots fail?

Because Redis cluster requires all keys in multi-key commands to be in the same hash slot. The execution_table row 5 shows the error due to keys in different slots.

How does the cluster know which node to send the command to?

It calculates the hash slot for the keys and routes the command to the node owning that slot, as shown in execution_table rows 1 and 2.

Visual Quiz - 3 Questions

Look at the execution_table, what is the result of the MSET command in step 2?

A Error due to keys in different slots

B Partial values set

C Command accepted and values set

D Redirect to another node

💡 Hint

See execution_table row 2 where both keys hash to the same slot and values are set.

At which step does the cluster detect keys in different slots causing an error?

A Step 5

B Step 1

C Step 3

D Step 4

💡 Hint

Check execution_table row 5 where keys key1 and key3 have different slots.

If key2 was in a different slot, what would happen to the MSET command?

A It would partially set keys

B It would fail with error or redirect

C It would succeed normally

D It would ignore key2

💡 Hint

Refer to the cluster rule in concept_flow and execution_table row 5 about multi-key commands requiring same slot.

Concept Snapshot

Multi-key operations in Redis cluster require all keys to be in the same hash slot.
Cluster routes commands to the node owning that slot.
If keys span multiple slots, commands fail or redirect.
Use hash tags { } to force keys into same slot.
Example: MSET {user1}name "Alice" {user1}age 30

Full Transcript

In Redis cluster, multi-key commands like MSET or MGET only work if all keys belong to the same hash slot. The cluster calculates the hash slot for each key. If all keys share the same slot, the command is sent to the node owning that slot and executes successfully. If keys belong to different slots, the cluster returns an error or a redirect message. This is because Redis cluster distributes keys across nodes by hash slots to scale horizontally. To ensure multi-key commands work, keys can use hash tags (curly braces) to force them into the same slot. For example, keys like {user1}name and {user1}age hash to the same slot. This visual trace showed step-by-step how commands are routed and executed, and when errors occur due to slot mismatches.

Practice

1. In a Redis cluster, why must keys be in the same hash slot for multi-key operations?

easy

A. Because Redis cluster does not support multi-key commands at all

B. Because keys in different slots cause syntax errors

C. Because keys in different slots are automatically merged

D. Because Redis cluster routes commands to a single node per hash slot

Solution

1. Step 1: Understand Redis cluster hash slots

   Redis cluster divides keys into 16384 hash slots, each handled by one node.

2. Step 2: Multi-key commands require single node routing

   Multi-key commands must operate on keys in the same slot to be routed to one node.

3. Final Answer:

   Because Redis cluster routes commands to a single node per hash slot -> Option D

4. Quick Check:

   Same hash slot = single node routing [OK]

Hint: Keys must share hash slot for multi-key commands [OK]

Common Mistakes:

• Thinking keys in different slots can be used together
• Assuming multi-key commands work cluster-wide automatically
• Confusing syntax errors with routing errors

2. Which of the following is the correct syntax to ensure two keys are in the same hash slot using key tags?

easy

A. SET user:1:name 'Alice'
SET user:1:age 30

B. SET {user:1}:name 'Alice'
SET {user:1}:age 30

C. SET {user1}:1:name 'Alice'
SET {user}:1:age 30

D. SET {user:1:name} 'Alice'
SET {user:1:age} 30

Solution

1. Step 1: Identify key tag usage

   Key tags are enclosed in curly braces {} and define the hash slot.

2. Step 2: Check which keys share the same tag

   Keys with the same substring inside {} share the same slot, e.g., {user:1}.

3. Final Answer:

   SET {user:1}:name 'Alice' and SET {user:1}:age 30 -> Option B

4. Quick Check:

   Same key tag inside {} means same slot [OK]

Hint: Use identical curly braces content for same slot keys [OK]

Common Mistakes:

• Placing braces incorrectly around parts of the key
• Using different tags for keys meant to be grouped
• Omitting braces and expecting same slot

3. Given these Redis commands in a cluster:

SET {order}:1001:status 'pending'
SET {order}:1001:amount 250
MGET {order}:1001:status {order}:1001:amount

What will be the output of the MGET command?

medium

A. ["pending", "250"]

B. ["pending", null]

C. [null, "250"]

D. Error: CROSSSLOT Keys in request don't hash to the same slot

Solution

1. Step 1: Check keys and their hash slots

   Both keys have the same tag {order}, so they share the same slot.

2. Step 2: Verify keys exist and MGET output

   Both keys were set, so MGET returns their values in order: 'pending' and '250'.

3. Final Answer:

   ["pending", "250"] -> Option A

4. Quick Check:

   Same slot keys return values correctly [OK]

Hint: MGET works if keys share same hash slot [OK]

Common Mistakes:

• Expecting CROSSSLOT error despite same key tags
• Confusing string and integer values
• Assuming null for existing keys

4. You run this Redis cluster command:

MGET user:1:name user:2:name

But get an error: CROSSSLOT Keys in request don't hash to the same slot. What is the best fix?

medium

A. Use key tags to put both keys in the same hash slot, e.g., {user}:1:name and {user}:2:name

B. Run the command on each key separately

C. Rename keys to have the same prefix without braces

D. Disable cluster mode to allow multi-key commands

Solution

1. Step 1: Understand CROSSSLOT error cause

   Keys user:1:name and user:2:name hash to different slots, causing the error.

2. Step 2: Use key tags to group keys

   Adding the same tag in braces, e.g., {user}, forces keys into the same slot.

3. Final Answer:

   Use key tags to put both keys in the same hash slot, e.g., {user}:1:name and {user}:2:name -> Option A

4. Quick Check:

   Key tags fix CROSSSLOT errors [OK]

Hint: Add identical key tags in braces to fix CROSSSLOT [OK]

Common Mistakes:

• Ignoring the error and retrying same command
• Assuming prefix alone groups keys
• Trying to disable cluster mode without reason

5. You want to atomically increment two counters in a Redis cluster using a multi-key command. The counters are counter:{2024}:a and counter:{2024}:b. Which approach correctly increments both counters in one command without errors?

hard

A. Use INCR counter:2024:a and INCR counter:2024:b separately

B. Use INCR counter:{2024}:a counter:{2024}:b in one command

C. Use MULTI with two INCR commands on the keys, then EXEC

D. Use INCR counter:{2024}:a and INCR counter:{2025}:b in a pipeline

Solution

1. Step 1: Confirm keys share the same hash slot

   Both keys have the same tag {2024}, so they are in the same slot.

2. Step 2: Use MULTI/EXEC for atomic multi-key operations

   Redis supports atomic transactions with MULTI/EXEC on keys in the same slot.

3. Final Answer:

   Use MULTI with two INCR commands on the keys, then EXEC -> Option C

4. Quick Check:

   Atomic multi-key needs MULTI/EXEC and same slot keys [OK]

Hint: Use MULTI/EXEC with same-slot keys for atomic multi-key ops [OK]

Common Mistakes:

• Trying to INCR multiple keys in one command
• Using keys without same hash tag
• Assuming pipeline is atomic