Cluster architecture in Redis - Deep Dive

Overview - Cluster architecture

What is it?

Cluster architecture in Redis is a way to spread data across multiple servers, called nodes, so that the system can handle more data and more users at the same time. It divides the data into parts called slots and assigns these slots to different nodes. This setup helps Redis work faster and stay available even if some nodes fail.

Why it matters

Without cluster architecture, Redis would be limited to the capacity of a single server, making it hard to handle large amounts of data or many users. If that server fails, all data becomes unavailable. Cluster architecture solves this by distributing data and workload, improving speed, reliability, and scalability, which is crucial for real-time applications like messaging, caching, and gaming.

Where it fits

Before learning Redis cluster architecture, you should understand basic Redis concepts like keys, values, and single-node operation. After mastering cluster architecture, you can explore advanced topics like data sharding, replication, failover, and Redis Sentinel for high availability.

Mental Model

Core Idea

Redis cluster architecture splits data into slots and distributes them across multiple nodes to balance load and ensure availability.

Think of it like...

Imagine a library where books are divided into sections, and each section is managed by a different librarian. If one librarian is busy or absent, others still manage their sections, so the library keeps running smoothly.

┌─────────────┐      ┌─────────────┐      ┌─────────────┐
│   Node 1    │      │   Node 2    │      │   Node 3    │
│ Slots 0-5460│      │ Slots 5461- │      │ Slots 10923-│
│             │      │ 10922       │      │ 16383       │
└─────┬───────┘      └─────┬───────┘      └─────┬───────┘
      │                    │                    │
      └─────── Data Slots Distributed Across Nodes ────────┘

Build-Up - 6 Steps

1

Foundation

Understanding Redis Data Slots

Concept: Redis cluster divides all keys into 16384 slots to organize data distribution.

Redis assigns each key to one of 16384 slots using a hash function. Each slot can be stored on a different node. This division helps Redis know exactly where to find or store a key without searching all nodes.

Result

Keys are mapped to specific slots, enabling organized data distribution.

Understanding slots is key to grasping how Redis knows where data lives in a cluster.

2

Foundation

Nodes and Their Roles in Cluster

Concept: A Redis cluster consists of multiple nodes, each responsible for a subset of slots, with roles like master or replica.

Nodes in a Redis cluster can be masters or replicas. Masters hold the actual data for their assigned slots. Replicas copy data from masters to provide backup and help with read requests. This setup improves reliability and performance.

Result

Cluster nodes have clear roles, ensuring data is stored and backed up properly.

Knowing node roles helps understand how Redis maintains data safety and availability.

3

Intermediate

How Data is Sharded Across Nodes

🤔Before reading on: do you think Redis copies all data to every node or splits it among nodes? Commit to your answer.

Concept: Redis shards data by assigning different slots to different master nodes, so each node holds only part of the data.

Instead of copying all data everywhere, Redis divides slots among master nodes. For example, if there are 3 masters, each might handle about 5461 slots. This way, data and workload are balanced, and no single node is overwhelmed.

Result

Data is split (sharded) across nodes, improving scalability and speed.

Understanding sharding explains how Redis scales horizontally by spreading data.

4

Intermediate

Failover and Replication in Cluster

🤔Before reading on: do you think Redis cluster stops working if a master node fails? Commit to your answer.

Concept: Redis cluster uses replicas to take over if a master node fails, ensuring continuous availability.

Each master node has one or more replicas. If a master fails, the cluster automatically promotes a replica to master. This failover process keeps the cluster running without manual intervention.

Result

Cluster remains available even if some nodes fail.

Knowing failover mechanisms reveals how Redis achieves high availability.

5

Advanced

Cluster Communication and Gossip Protocol

🤔Before reading on: do you think nodes in a Redis cluster communicate directly or only through clients? Commit to your answer.

Concept: Redis nodes communicate with each other using a gossip protocol to share cluster state and detect failures.

Nodes regularly exchange information about their status and the cluster state using a gossip protocol. This helps nodes detect if others are down and coordinate failover and slot reassignments.

Result

Cluster nodes stay synchronized and can react quickly to changes.

Understanding internal communication explains how Redis cluster self-manages without central control.

6

Expert

Handling Slot Migration and Rebalancing

🤔Before reading on: do you think slot assignments in Redis cluster are fixed forever or can change? Commit to your answer.

Concept: Redis cluster supports moving slots between nodes to rebalance load or during scaling operations.

When adding or removing nodes, Redis migrates slots from one node to another. This process involves copying keys for those slots and updating cluster state. Clients are informed to redirect requests during migration.

Result

Cluster can adapt dynamically to changes in size or load.

Knowing slot migration reveals how Redis cluster maintains balance and scalability in production.

Under the Hood

Redis cluster uses a hash slot mechanism where each key is hashed to a slot number between 0 and 16383. Each master node owns a subset of these slots. Nodes communicate using a gossip protocol to share cluster state and detect failures. Replicas replicate data asynchronously from masters. When a master fails, a replica is promoted through consensus among nodes. Slot migration involves copying keys and updating slot ownership atomically to avoid data loss or inconsistency.

Why designed this way?

Redis cluster was designed to avoid a single point of failure and to scale horizontally without complex coordination. The fixed number of slots simplifies key distribution and lookup. Gossip protocol allows decentralized state sharing without a central coordinator, improving fault tolerance. Asynchronous replication balances performance and data safety. Slot migration supports dynamic scaling, which is essential for real-world usage.

┌───────────────┐      ┌───────────────┐      ┌───────────────┐
│   Client      │─────▶│   Node 1      │◀────▶│   Node 2      │
│               │      │ (Master Slots)│      │ (Master Slots)│
└───────────────┘      └───────┬───────┘      └───────┬───────┘
                               │                      │
                      ┌────────┴────────┐   ┌─────────┴────────┐
                      │   Replica Node  │   │   Replica Node   │
                      └─────────────────┘   └──────────────────┘

Nodes exchange cluster state via gossip protocol and handle slot migration and failover.

Myth Busters - 4 Common Misconceptions

Quick: Does Redis cluster replicate all data to every node? Commit to yes or no.

Common Belief: Redis cluster copies all data to every node for safety.

Reality: Redis cluster shards data so each master node holds only a subset of slots; replicas copy only their master's data.

Why it matters: Believing all data is on every node leads to wrong assumptions about memory use and performance, causing poor cluster design.

Quick: If a master node fails, does the cluster stop working? Commit to yes or no.

Common Belief: If a master node fails, the Redis cluster becomes unavailable.

Reality: The cluster promotes a replica to master automatically, keeping the cluster available.

Why it matters: Not knowing failover exists can cause unnecessary panic and downtime during node failures.

Quick: Are slot assignments permanent and unchangeable? Commit to yes or no.

Common Belief: Slot assignments to nodes are fixed and cannot be changed after cluster setup.

Reality: Slots can be migrated between nodes to rebalance load or add/remove nodes.

Why it matters: Thinking slots are fixed limits the ability to scale or maintain the cluster effectively.

Quick: Do clients always connect to a single node for all requests? Commit to yes or no.

Common Belief: Clients connect to one node and that node handles all requests internally.

Reality: Clients must be aware of cluster topology and may be redirected to the correct node for a key's slot.

Why it matters: Misunderstanding client behavior can cause inefficient queries and errors in distributed setups.

Expert Zone

1

Redis cluster uses asynchronous replication which can cause brief data loss during failover, a tradeoff for performance.

2

The fixed number of 16384 slots is a design choice balancing granularity and management complexity; changing this number is not supported.

3

Clients must implement smart routing or use cluster-aware libraries to handle MOVED and ASK redirections efficiently.

When NOT to use

Redis cluster is not ideal for workloads requiring strong consistency or multi-key transactions across slots. In such cases, consider Redis Sentinel for high availability on a single node or other distributed databases with stronger consistency guarantees.

Production Patterns

In production, Redis clusters are often combined with replicas for read scaling and failover. Slot rebalancing is done during maintenance windows to avoid performance hits. Monitoring cluster health and using cluster-aware clients are standard practices to ensure smooth operation.

Connections

Distributed Hash Table (DHT)

Redis cluster's slot distribution is a form of DHT used in distributed systems.

Understanding DHT concepts helps grasp how Redis efficiently locates data in a distributed cluster.

Consensus Algorithms

Redis cluster uses a simple consensus among nodes to promote replicas during failover.

Knowing consensus principles clarifies how Redis achieves fault tolerance without a central coordinator.

Library Book Management

Like librarians managing different book sections, Redis nodes manage data slots.

This cross-domain view shows how dividing responsibility improves efficiency and availability.

Common Pitfalls

#1 Assigning all slots to a single node defeats clustering benefits.

Wrong approach:

CLUSTER ADDSLOTS 0 1 2 3 ... 16383 ON NODE node1

Correct approach:

Distribute slots evenly: NODE1 gets slots 0-5460, NODE2 gets 5461-10922, NODE3 gets 10923-16383

Root cause:

Misunderstanding slot distribution leads to uneven load and no scalability.

#2 Ignoring client redirection causes errors when keys are on different nodes.

Wrong approach:

Client sends all commands to one node without handling MOVED responses.

Correct approach:

Use cluster-aware clients that follow MOVED and ASK redirections to correct nodes.

Root cause:

Not implementing cluster-aware clients breaks request routing.

#3 Failing to configure replicas leads to no failover support.

Wrong approach:

Setting up cluster with only master nodes and no replicas.

Correct approach:

Assign replicas to each master node for backup and failover.

Root cause:

Overlooking replication reduces cluster availability.

Key Takeaways

Redis cluster architecture divides data into 16384 slots distributed across multiple nodes for scalability.

Master nodes hold data for assigned slots, while replicas provide backup and failover support.

Nodes communicate using a gossip protocol to share cluster state and detect failures.

Slot migration allows dynamic rebalancing when scaling the cluster up or down.

Clients must be cluster-aware to route requests correctly and handle node changes.

Practice

1.

What is the main purpose of Redis Cluster architecture?

easy

A. To backup data to external storage every minute

B. To store data only on a single server for simplicity

C. To encrypt data automatically on all nodes

D. To split data across multiple servers for better performance and fault tolerance

Solution

1. Step 1: Understand Redis Cluster design

   Redis Cluster splits data across multiple servers using hash slots to distribute load.

2. Step 2: Identify the main benefit

   This splitting improves speed, storage capacity, and fault tolerance by avoiding a single point of failure.

3. Final Answer:

   To split data across multiple servers for better performance and fault tolerance -> Option D

4. Quick Check:

   Redis Cluster = Data distribution + fault tolerance [OK]

Hint: Redis Cluster splits data for speed and safety [OK]

Common Mistakes:

• Thinking Redis Cluster stores data on one server
• Confusing cluster with encryption feature
• Assuming cluster only handles backups

2.

Which command line option is required to start a Redis node with cluster enabled?

redis-server --port 7000 --cluster-enabled ???

easy

A. yes

B. true

C. on

D. enable

Solution

1. Step 1: Recall Redis cluster start syntax

   To enable cluster mode, the option is --cluster-enabled yes.

2. Step 2: Confirm correct boolean value

   Redis expects 'yes' or 'no' for this flag, not 'true', 'on', or 'enable'.

3. Final Answer:

   yes -> Option A

4. Quick Check:

   Cluster enabled flag = yes [OK]

Hint: Use 'yes' to enable cluster mode in Redis [OK]

Common Mistakes:

• Using 'true' or 'on' instead of 'yes'
• Typing 'enable' which is invalid
• Omitting the cluster-enabled option

3.

Given a Redis Cluster with 3 nodes, each handling 5461 hash slots, what happens if one node fails?

Choose the correct behavior:

medium

A. All data on the failed node is lost permanently

B. The cluster stops working until the failed node is back

C. The cluster continues working if replicas exist for the failed node's slots

D. The cluster automatically merges all slots to remaining nodes

Solution

1. Step 1: Understand Redis Cluster fault tolerance

   Redis Cluster uses replicas to provide fault tolerance. If a node fails, replicas can take over its hash slots.

2. Step 2: Analyze failure impact

   If replicas exist, the cluster continues working by promoting replicas. Without replicas, cluster availability is affected.

3. Final Answer:

   The cluster continues working if replicas exist for the failed node's slots -> Option C

4. Quick Check:

   Node failure + replicas = cluster stays up [OK]

Hint: Replicas keep cluster alive if a node fails [OK]

Common Mistakes:

• Assuming cluster stops immediately on node failure
• Thinking data is lost without replicas
• Believing cluster merges slots automatically

4.

Identify the error in this Redis cluster node start command:

redis-server --port 7001 --cluster-enabled yes --cluster-config-file nodes-7001.conf --cluster-node-timeout 5000 --cluster-announce-ip 192.168.1.10 --cluster-announce-port 7001 --cluster-announce-bus-port 17001 --cluster-enabled no

medium

A. The command has conflicting cluster-enabled flags

B. The port number is invalid

C. The cluster-config-file name is incorrect

D. The cluster-node-timeout value is too low

Solution

1. Step 1: Review cluster-enabled flags

   The command has two --cluster-enabled flags: one set to 'yes' and another to 'no'. This is conflicting.

2. Step 2: Understand impact of conflicting flags

   Redis will use the last flag, disabling cluster mode, which contradicts other cluster options.

3. Final Answer:

   The command has conflicting cluster-enabled flags -> Option A

4. Quick Check:

   Conflicting flags cause cluster mode error [OK]

Hint: Avoid multiple cluster-enabled flags in one command [OK]

Common Mistakes:

• Ignoring repeated flags causing conflicts
• Assuming port 7001 is invalid
• Thinking config file name causes error

5.

You want to create a Redis Cluster with 6 nodes: 3 masters and 3 replicas. Which of the following is the correct approach to assign hash slots and replicas?

hard

A. Assign all hash slots to replicas only; masters hold no slots

B. Assign all 16384 hash slots evenly to 3 masters; assign each replica to a different master node

C. Assign hash slots randomly to all 6 nodes without replicas

D. Assign hash slots only to one master; others act as replicas

Solution

1. Step 1: Understand hash slot distribution

   Redis Cluster has 16384 hash slots. These should be evenly split among master nodes for balanced load.

2. Step 2: Assign replicas properly

   Each replica should be linked to a different master to provide fault tolerance and avoid single points of failure.

3. Final Answer:

   Assign all 16384 hash slots evenly to 3 masters; assign each replica to a different master node -> Option B

4. Quick Check:

   Slots evenly on masters + replicas assigned = correct cluster setup [OK]

Hint: Distribute slots evenly on masters; assign replicas per master [OK]

Common Mistakes:

• Assigning slots to replicas instead of masters
• Not linking replicas to masters
• Putting all slots on one master only