Multi-key operations in cluster in Redis - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ query_result

intermediate

What is the result of this Redis cluster multi-key command?

Given a Redis cluster with keys {user1}:name and {user1}:age stored in the same hash slot, what is the output of the command MGET {user1}:name {user1}:age if {user1}:name = "Alice" and {user1}:age = "30"?

Redis

MGET {user1}:name {user1}:age

A [null, null]

B ["Alice"]

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

D ["Alice", "30"]

💡 Hint

Keys with the same hash tag (inside {}) are stored in the same slot and can be accessed together.

In Redis Cluster, keys with the same hash tag (the part inside curly braces) are stored in the same slot, allowing multi-key commands like MGET to work without error. Since both keys exist with values "Alice" and "30", MGET returns both values in order.

🧠 Conceptual

intermediate

Why does Redis Cluster reject multi-key commands on keys without the same hash tag?

In Redis Cluster, why does a command like MGET key1 key2 fail with a CROSSSLOT error if key1 and key2 do not share the same hash tag?

A Because keys must be in the same hash slot to ensure atomicity and consistency of multi-key operations.

B Because keys with different names cannot be accessed together.

C Because Redis Cluster does not support multi-key commands at all.

D Because the keys are stored in the same slot but the command syntax is invalid.

💡 Hint

Think about how Redis Cluster distributes keys and why atomic operations need keys in the same slot.

Redis Cluster partitions data by hash slots. Multi-key commands require all keys to be in the same slot to guarantee atomicity and avoid inconsistent states. If keys hash to different slots, the command fails with CROSSSLOT error.

📝 Syntax

advanced

Which command syntax correctly performs a multi-key increment in Redis Cluster?

You want to increment two counters stored as keys {counter}:a and {counter}:b atomically in Redis Cluster. Which command syntax is valid?

A INCR {counter}:a {counter}:b

B

MULTI
INCR {counter}:a
INCR {counter}:b
EXEC

C MSET {counter}:a {counter}:b

D INCR {counter}:a; INCR {counter}:b

💡 Hint

Consider how Redis transactions work and how multi-key commands are handled in clusters.

MULTI/EXEC starts a transaction block. Inside it, multiple commands like INCR can be queued and executed atomically. Option B correctly uses MULTI/EXEC with two INCR commands on keys sharing the same hash tag.

❓ optimization

advanced

How to optimize multi-key reads in Redis Cluster when keys have different hash tags?

You need to read values of keys user:1:name and user:2:name in Redis Cluster, but they hash to different slots. What is the best approach to optimize multi-key reads?

A Use MGET command directly on both keys.

B Rename keys to have the same hash tag and use MGET.

C Use pipelining to send multiple GET commands in one network round-trip.

D Use Lua scripting to read both keys atomically.

💡 Hint

Think about how to reduce network latency when keys are in different slots.

Since keys are in different slots, MGET fails. Renaming keys may not be feasible. Lua scripts cannot access multiple slots atomically. Pipelining sends multiple commands in one go, reducing latency and improving performance.

🔧 Debug

expert

Why does this Redis Cluster multi-key command fail with CROSSSLOT error?

You run the command MGET user:100:name user:101:name in a Redis Cluster and get the error: CROSSSLOT Keys in request don't hash to the same slot. Both keys exist. What is the root cause?

Redis

MGET user:100:name user:101:name

A The keys hash to different slots because they lack a common hash tag.

B The keys do not exist in the cluster.

C The MGET command is not supported in Redis Cluster.

D The keys are locked by another client.

💡 Hint

Check how Redis Cluster calculates hash slots for keys without explicit hash tags.

Without explicit hash tags (the part inside {}), Redis Cluster hashes the entire key name, so keys with different suffixes hash to different slots. Multi-key commands require keys in the same slot, so this causes CROSSSLOT error.

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