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.