Multi-key operations in cluster in Redis - Deep Dive

Overview - Multi-key operations in cluster

What is it?

Multi-key operations in a Redis cluster involve commands that work with more than one key at the same time. In a cluster, data is split across multiple nodes, so keys may be stored on different servers. This makes some multi-key commands tricky because they need all keys to be on the same node to work properly.

Why it matters

Without understanding multi-key operations in a cluster, you risk running commands that fail or cause slow performance. This can break your application or cause data inconsistency. Knowing how Redis handles keys in a cluster helps you design your data and commands so they work smoothly and efficiently.

Where it fits

Before this, you should understand basic Redis commands and how Redis clustering works, including key hashing and slot distribution. After this, you can learn about advanced cluster management, Lua scripting in clusters, and optimizing Redis for high availability and performance.

Mental Model

Core Idea

In a Redis cluster, multi-key commands only work if all keys are stored on the same node, because each node handles a subset of keys based on hashing.

Think of it like...

Imagine a library where books are stored in different rooms based on their topic. If you want to compare two books, they must be in the same room; otherwise, you have to walk between rooms, which takes time and effort.

┌─────────────┐       ┌─────────────┐       ┌─────────────┐
│ Node 1     │       │ Node 2     │       │ Node 3     │
│ Slots 0-5460│       │ Slots 5461-10922│    │ Slots 10923-16383│
│ Keys: A,B,C │       │ Keys: D,E,F │       │ Keys: G,H,I │
└─────┬───────┘       └─────┬───────┘       └─────┬───────┘
      │                     │                     │
      │ Multi-key command requires keys on same node
      │ If keys are on different nodes, command fails or is unsupported

Build-Up - 7 Steps

1

Foundation

Basics of Redis Cluster Key Distribution

Concept: Redis cluster splits keys across nodes using hash slots.

Redis cluster divides all possible keys into 16,384 hash slots. Each node in the cluster is responsible for a subset of these slots. When you add a key, Redis calculates its hash slot and stores the key on the node responsible for that slot.

Result

Keys are distributed evenly across nodes, allowing Redis to scale horizontally.

Understanding how keys are distributed is essential because multi-key commands depend on keys being on the same node.

2

Foundation

What Are Multi-key Commands in Redis?

Concept: Some Redis commands work with multiple keys at once, like MGET or MSET.

Commands like MGET (get multiple keys), MSET (set multiple keys), and DEL (delete multiple keys) operate on several keys in one command. In a single-node Redis, these commands are straightforward because all keys are in one place.

Result

Multi-key commands simplify batch operations and improve performance by reducing round trips.

Knowing which commands are multi-key helps you understand why clustering complicates their use.

3

Intermediate

Why Multi-key Commands Are Limited in Clusters

🤔Before reading on: do you think Redis cluster allows multi-key commands across any keys on different nodes? Commit to yes or no.

Concept: Multi-key commands only work if all keys are in the same hash slot (same node).

Because each node handles only a subset of keys, Redis cluster requires all keys in a multi-key command to be on the same node. If keys are on different nodes, the command will fail or be rejected. This is because Redis cannot coordinate multi-key operations across nodes atomically.

Result

Multi-key commands across different nodes are not supported, causing errors or limitations.

Understanding this limitation prevents confusion and helps design keys to be co-located.

4

Intermediate

Using Key Hash Tags to Group Keys

🤔Before reading on: do you think Redis cluster can force keys to be stored together? Commit to yes or no.

Concept: Redis allows forcing keys to share the same hash slot using hash tags.

By placing a part of the key inside curly braces {}, called a hash tag, you tell Redis to hash only that part. For example, keys {user}:1 and {user}:2 will be stored on the same node. This enables multi-key commands on those keys.

Result

Keys with the same hash tag are stored on the same node, enabling multi-key commands.

Knowing how to use hash tags is key to overcoming multi-key command limitations in clusters.

5

Intermediate

Common Multi-key Commands Supported in Clusters

Concept: Some multi-key commands work if keys share the same hash slot.

Commands like MGET, MSET, DEL, and EXISTS can be used on multiple keys if those keys are in the same hash slot. If keys are not co-located, these commands will fail. Redis cluster clients often check or enforce this before sending commands.

Result

Multi-key commands succeed only when keys are co-located; otherwise, they fail.

Recognizing which commands support multi-key operations in clusters helps avoid runtime errors.

6

Advanced

Handling Multi-key Operations Across Nodes

🤔Before reading on: do you think Redis cluster supports automatic multi-node multi-key commands? Commit to yes or no.

Concept: Redis cluster does not support multi-key commands across nodes; clients must handle this.

If you need to operate on keys across different nodes, you must send separate commands to each node and combine results in your application. Some client libraries provide helpers to do this transparently, but it is not atomic and can be slower.

Result

Multi-key operations across nodes require manual or client-side coordination.

Knowing this limitation guides you to design your application logic or use client features for multi-node operations.

7

Expert

Internal Cluster Coordination and Multi-key Limitations

🤔Before reading on: do you think Redis cluster nodes communicate to execute multi-key commands atomically? Commit to yes or no.

Concept: Redis cluster nodes do not coordinate multi-key commands across nodes to keep performance and simplicity.

Each Redis cluster node operates independently on its hash slots. There is no built-in distributed transaction or locking mechanism across nodes. This design avoids complexity and latency but means multi-key commands must be limited to single nodes.

Result

Multi-key commands are atomic only within a node; cross-node atomicity is not supported.

Understanding this design explains why multi-key commands have cluster limitations and why Redis favors speed and simplicity over distributed transactions.

Under the Hood

Redis cluster uses a hash function to assign each key to one of 16,384 slots. Each node owns a subset of these slots and stores keys accordingly. Multi-key commands require all keys to hash to the same slot so the command can be executed on a single node. If keys hash to different slots, the cluster cannot execute the command atomically or efficiently because nodes do not communicate to coordinate multi-key operations.

Why designed this way?

This design was chosen to keep Redis cluster fast and simple. Distributed transactions or cross-node locking would add complexity, latency, and risk of deadlocks. By restricting multi-key commands to keys in the same slot, Redis ensures high performance and scalability while encouraging developers to design data for co-location.

┌───────────────┐
│ Client sends  │
│ multi-key cmd │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Hash keys to  │
│ slots         │
└──────┬────────┘
       │
       ▼
┌───────────────┐       ┌───────────────┐
│ Node A owns   │       │ Node B owns   │
│ slots 0-5460  │       │ slots 5461-   │
│               │       │ 10922         │
│ Keys: K1,K2   │       │ Keys: K3,K4   │
└──────┬────────┘       └──────┬────────┘
       │                       │
       │ If all keys in same   │
       │ slot, execute command │
       │ on one node           │
       │                       │
       │ If keys in different  │
       │ slots, command fails  │
       ▼                       ▼
┌───────────────┐       ┌───────────────┐
│ Execute cmd   │       │ Reject cmd or │
│ atomically on │       │ error         │
│ Node A        │       └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do multi-key commands in Redis cluster always work regardless of key location? Commit to yes or no.

Common Belief: Multi-key commands like MGET or MSET work the same in Redis cluster as in single-node Redis.

Reality: Multi-key commands only work if all keys are in the same hash slot (same node). Otherwise, they fail or are rejected.

Why it matters: Assuming multi-key commands always work leads to runtime errors and broken applications in cluster environments.

Quick: Can Redis cluster automatically move keys to the same node to support multi-key commands? Commit to yes or no.

Common Belief: Redis cluster automatically relocates keys to support multi-key commands across nodes.

Reality: Redis cluster does not move keys automatically for multi-key commands; key placement is fixed unless manually re-sharded.

Why it matters: Expecting automatic key relocation causes confusion and poor design decisions, leading to failed commands.

Quick: Is it possible to have atomic multi-key operations across multiple nodes in Redis cluster? Commit to yes or no.

Common Belief: Redis cluster supports atomic multi-key operations across nodes using internal coordination.

Reality: Redis cluster does not support atomic multi-key operations across nodes; atomicity is limited to keys on the same node.

Why it matters: Believing in cross-node atomicity can cause data inconsistency and race conditions in distributed applications.

Quick: Does using hash tags guarantee multi-key commands will always work? Commit to yes or no.

Common Belief: Using hash tags always solves multi-key command issues in Redis cluster.

Reality: Hash tags only work if used correctly and consistently; misuse or inconsistent tagging breaks key co-location.

Why it matters: Incorrect use of hash tags leads to unexpected command failures and debugging challenges.

Expert Zone

1

Multi-key commands in clusters require careful key naming conventions to ensure co-location, which can complicate schema design.

2

Client libraries often implement checks or split multi-key commands into multiple single-key commands to handle cluster limitations transparently.

3

Redis cluster's choice to avoid distributed transactions favors performance but requires application-level logic for complex multi-key workflows.

When NOT to use

Avoid multi-key commands in clusters when keys cannot be co-located; instead, use single-key commands or client-side aggregation. For atomic multi-key operations across nodes, consider Redis Enterprise or external transaction managers.

Production Patterns

In production, developers use hash tags to group related keys, design data models for co-location, and rely on client libraries that handle multi-key commands safely. Batch operations are split per node, and Lua scripts are used cautiously within single nodes.

Connections

Distributed Transactions

Redis cluster's multi-key limitations contrast with distributed transaction systems that coordinate across nodes.

Understanding Redis cluster's lack of distributed transactions clarifies why multi-key commands are restricted and why some systems choose more complex coordination.

Hash Functions

Redis cluster uses hash functions to assign keys to nodes, directly impacting multi-key command feasibility.

Knowing how hash functions distribute keys helps in designing keys for co-location and efficient multi-key operations.

Library Book Organization

Like organizing books by topic in rooms, Redis cluster organizes keys by hash slots in nodes.

This cross-domain view helps grasp why multi-key commands need keys in the same 'room' (node) to work.

Common Pitfalls

#1 Trying to run MGET on keys stored on different cluster nodes.

Wrong approach:

MGET key1 key2 key3 # keys hash to different nodes

Correct approach:

MGET {user}:1 {user}:2 {user}:3 # keys share hash tag and node

Root cause:

Not understanding that multi-key commands require keys to be on the same node in a cluster.

#2 Using inconsistent hash tags causing keys to be stored on different nodes.

Wrong approach:

SET user:1 value1
SET {user}:2 value2

Correct approach:

SET {user}:1 value1
SET {user}:2 value2

Root cause:

Misusing hash tags by not applying them consistently to all related keys.

#3 Expecting atomic multi-key operations across nodes without additional coordination.

Wrong approach:

Performing multi-key transactions spanning keys on different nodes.

Correct approach:

Split operations per node or use single-node Lua scripts for atomicity.

Root cause:

Misunderstanding Redis cluster's design that limits atomicity to single nodes.

Key Takeaways

Redis cluster distributes keys across nodes using hash slots, affecting multi-key command behavior.

Multi-key commands only work if all keys are stored on the same node, identified by sharing the same hash slot.

Hash tags allow forcing keys to be stored together, enabling multi-key commands in clusters.

Redis cluster does not support atomic multi-key operations across nodes, requiring application-level handling.

Understanding these limits helps design Redis data and commands for reliable and efficient cluster use.

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