Client-side cluster support in Redis - Step-by-Step Execution

Concept Flow - Client-side cluster support

Client starts

↓

Fetch cluster slots info

↓

Build slots-to-node map

↓

Send command to correct node based on key hash

↓

Receive response

↓

If MOVED or ASK error

↓

Update slots map

↓

Retry command if needed

↓

End

The client fetches cluster slot info, maps keys to nodes, sends commands to the right node, handles redirects, and updates its map as needed.

Execution Sample

Redis

CLUSTER SLOTS
SET key1 value1
GET key1

Client fetches cluster slots, then sets and gets a key routed to the correct node.

Execution Table

Step	Action	Command Sent	Node Targeted	Response	Client Map Update
1	Fetch cluster slots info	CLUSTER SLOTS	Any node	Slots info with node ranges	Build slots-to-node map
2	Send SET command	SET key1 value1	Node for key1 slot	OK	No change
3	Send GET command	GET key1	Node for key1 slot	value1	No change
4	If MOVED or ASK error received	Retry command	Updated node	OK or value1	Update slots-to-node map
5	Return final response	N/A	N/A	value1	N/A

💡 Commands complete successfully or after handling MOVED redirects and updating client map.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
slots_to_node_map	empty	populated with slot ranges and nodes	unchanged	unchanged	updated if MOVED or ASK error	final updated map
command	none	none	SET key1 value1	GET key1	retry if needed	none
response	none	slots info	OK	value1	OK or value1	value1

Key Moments - 3 Insights

Why does the client need to fetch cluster slots info first?

The client uses the slots info to know which node holds which key range, so it can send commands directly to the correct node (see execution_table step 1).

What happens if the client sends a command to the wrong node?

The server replies with a MOVED or ASK error, prompting the client to update its slots map and retry the command on the correct node (see execution_table step 4).

Does the client update its slots map after every command?

No, it updates only when it receives a MOVED or ASK error indicating the cluster topology changed (see execution_table steps 4 and 5).

Visual Quiz - 3 Questions

Look at the execution_table, at which step does the client build the slots-to-node map?

A Step 2

B Step 3

C Step 1

D Step 4

💡 Hint

Check the 'Client Map Update' column in execution_table row for Step 1.

According to variable_tracker, what is the state of 'response' after Step 3?

A "OK"

B "value1"

C "slots info"

D "none"

💡 Hint

Look at the 'response' row and the 'After Step 3' column in variable_tracker.

If the client receives a MOVED error, what does it do next according to the execution_table?

A Update slots map and retry command

B Ignore and return error to user

C Restart cluster

D Send command to random node

💡 Hint

See execution_table step 4 under 'Client Map Update' and 'Action'.

Concept Snapshot

Client-side cluster support:
- Client fetches cluster slots info with CLUSTER SLOTS.
- Builds a map of slots to nodes.
- Routes commands to correct node based on key hash slot.
- Handles MOVED/ASK errors by updating map and retrying.
- Ensures commands reach correct node without server-side proxy.

Full Transcript

Client-side cluster support in Redis means the client first asks the cluster for slot information using the CLUSTER SLOTS command. This tells the client which node is responsible for which key ranges. The client then builds a map from slots to nodes. When the client sends commands like SET or GET, it calculates the key's slot and sends the command directly to the correct node. If the client sends a command to the wrong node, the server replies with a MOVED or ASK error. The client then updates its slots map and retries the command on the right node. This process ensures efficient routing of commands in a Redis cluster without extra server-side proxying.

Practice

1. What is the main benefit of using client-side cluster support in Redis?

easy

A. It encrypts all data stored in Redis without extra setup.

B. It reduces the size of the Redis database automatically.

C. It merges all cluster nodes into a single server.

D. It allows the client to connect directly to the correct Redis node in the cluster.

Solution

1. Step 1: Understand client-side cluster support

   Client-side cluster support means the client knows how to talk to the right Redis node directly.

2. Step 2: Identify the main benefit

   This direct connection helps speed up requests and balances load across nodes.

3. Final Answer:

   It allows the client to connect directly to the correct Redis node in the cluster. -> Option D

4. Quick Check:

   Client-side cluster support = direct node connection [OK]

Hint: Client-side cluster means client talks directly to right node [OK]

Common Mistakes:

• Thinking it reduces database size automatically
• Confusing encryption with cluster support
• Believing it merges nodes into one server

2. Which of the following is the correct way to initialize a Redis client with cluster support in code?

easy

A. redis.createClient({ cluster: true, nodes: [...] })

B. redis.connectCluster(nodes)

C. redis.clusterConnect({ nodes: [...] })

D. redis.newClusterClient(nodes)

Solution

1. Step 1: Recall Redis client cluster initialization syntax

   The standard way is to create a client with cluster option and provide nodes list.

2. Step 2: Match syntax to options

   redis.createClient({ cluster: true, nodes: [...] }) matches the known syntax: redis.createClient({ cluster: true, nodes: [...] }). Others are invalid method names.

3. Final Answer:

   redis.createClient({ cluster: true, nodes: [...] }) -> Option A

4. Quick Check:

   Correct cluster client init = createClient with cluster true [OK]

Hint: Use createClient with cluster:true and nodes array [OK]

Common Mistakes:

• Using non-existent methods like connectCluster
• Forgetting to set cluster: true
• Passing nodes incorrectly

3. Given a Redis cluster with nodes at ports 7000 and 7001, what will the following code do?

const client = redis.createClient({ cluster: true, nodes: [ { port: 7000 }, { port: 7001 } ] });
await client.connect();
await client.set('key1', 'value1');
const val = await client.get('key1');
console.log(val);

medium

A. It will print 'value1' after storing the key in the correct cluster node.

B. It will throw an error because set is not supported in cluster mode.

C. It will print null because the key is not stored.

D. It will connect only to port 7000 and ignore 7001.

Solution

1. Step 1: Understand cluster client behavior on set/get

   The client connects to multiple nodes and routes commands to the right node based on key hashing.

2. Step 2: Analyze code flow

   It sets 'key1' with 'value1' and then gets 'key1'. The client handles routing, so get returns 'value1'.

3. Final Answer:

   It will print 'value1' after storing the key in the correct cluster node. -> Option A

4. Quick Check:

   Cluster client routes keys correctly = prints value1 [OK]

Hint: Cluster client routes keys, so get returns stored value [OK]

Common Mistakes:

• Thinking set/get are unsupported in cluster mode
• Assuming only one node is used
• Expecting null because of cluster complexity

4. You wrote this code to connect to a Redis cluster but get a connection error:

const client = redis.createClient({ cluster: true, nodes: [ { port: 7000 } ] });
await client.connect();

What is the most likely cause?

medium

A. The client library does not support cluster mode.

B. The port 7000 is incorrect; cluster nodes use port 6379.

C. You need to provide at least two nodes for cluster support.

D. You forgot to set cluster: false in options.

Solution

1. Step 1: Check cluster node requirements

   For cluster support, the client should know multiple nodes to discover the cluster topology.

2. Step 2: Analyze given nodes array

   Only one node is provided, so the client cannot properly discover the cluster, causing connection errors.

3. Final Answer:

   You need to provide at least two nodes for cluster support. -> Option C

4. Quick Check:

   Cluster client needs multiple nodes to connect [OK]

Hint: Provide multiple nodes to connect to cluster [OK]

Common Mistakes:

• Assuming single node is enough for cluster
• Confusing default Redis port with cluster ports
• Misconfiguring cluster option

5. You want to optimize your Redis cluster client to handle failover smoothly. Which approach best uses client-side cluster support to achieve this?

hard

A. Connect only to the master node and manually switch to replicas on failure.

B. Configure the client with multiple cluster nodes and enable automatic node discovery and retries.

C. Disable cluster mode and connect to nodes one by one in round-robin fashion.

D. Use a single client connection and restart it on any error.

Solution

1. Step 1: Understand failover handling in cluster clients

   Good cluster clients support automatic discovery of nodes and retry commands on failover.

2. Step 2: Evaluate options for smooth failover

   Configure the client with multiple cluster nodes and enable automatic node discovery and retries. uses multiple nodes and automatic discovery, which helps the client adapt to cluster changes without manual intervention.

3. Final Answer:

   Configure the client with multiple cluster nodes and enable automatic node discovery and retries. -> Option B

4. Quick Check:

   Automatic discovery and retries = smooth failover [OK]

Hint: Use multiple nodes and enable auto discovery for failover [OK]

Common Mistakes:

• Relying on manual failover switching
• Disabling cluster mode loses benefits
• Restarting client on every error is inefficient