Why Multi-key operations in cluster in Redis? - Purpose & Use Cases

The Big Idea

What if you could get many pieces of data at once without running all over the place?

The Scenario

Imagine you have a huge phone book split into many boxes, each box stored in a different city. You want to find phone numbers for several friends, but you have to visit each city one by one to check each box manually.

The Problem

Manually checking each box is slow and tiring. You might forget which city you checked or mix up the boxes. It's easy to make mistakes and waste a lot of time traveling back and forth.

The Solution

Multi-key operations in a Redis cluster let you ask for many phone numbers at once, but only if they are stored in the same city (or cluster slot). This way, you get all the answers quickly without running around.

Before vs After

✗ Before

GET key1
GET key2
GET key3

✓ After

MGET key1 key2 key3

What It Enables

This concept lets you efficiently retrieve or update multiple pieces of data in one go, making your app faster and simpler.

Real Life Example

A social media app fetching multiple user profiles stored across a Redis cluster can quickly get all needed profiles if they share the same cluster slot, improving load times and user experience.

Key Takeaways

Manual multi-key access across a cluster is slow and error-prone.

Multi-key operations work efficiently when keys share the same cluster slot.

This speeds up data retrieval and simplifies your code.

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