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.