Mastering Redis Clustering: Replication, Sentinel, and Sharding Explained

1. Redis Cluster Solutions

Redis provides three cluster solutions (each node usually under 10 GB memory): master‑slave replication, Sentinel mode, and sharding cluster.

2. Master‑Slave Replication

2.1 Definition

Master‑slave replication copies data from a master Redis server to one or more slave servers. The master (Master) sends data unidirectionally to slaves (Slave). By default each server is a master; a master can have multiple slaves, but a slave has only one master.

Architecture diagram:

2.2 How to Build a Master‑Slave Architecture

In master‑slave mode, the master handles read/write, while slaves are read‑only. Data is synchronized to keep nodes consistent.

Assume three machines A, B, C; A is the master.

① Basic configuration: install Redis on all three nodes, copy A’s config to B and C, then start Redis. ② Enable replication: use replicaof (or slaveof in older versions) command. Two ways: temporary (via redis‑cli, lost after restart) or permanent (add slaveof <masterip> <masterport> to redis.conf).

2.3 Replication Synchronization Principles

2.3.1 Full Synchronization

During full sync, the master performs a bgsave to generate an RDB file and sends it to the slave. Commands executed during bgsave are stored in repl_backlog and sent after the RDB, ensuring consistency.

Replication Id (replid) and offset are used to detect first‑time connections.

2.3.2 Incremental Synchronization

After the initial full sync, subsequent updates are sent as incremental changes based on the offset stored in repl_backlog.

2.4 Advantages and Disadvantages

Advantage: solves high‑concurrency read load. Disadvantage: does not guarantee high availability, which leads to the need for Sentinel.

3. Sentinel Mode

3.1 Purpose

1. Monitoring 2. Automatic failover 3. Notifying Redis clients

Sentinel runs as an independent process that continuously checks master and slave health, promotes a slave to master on failure, and informs clients of the new topology.

3.2 Monitoring (Heartbeat) and Election Rules

3.2.1 Heartbeat Mechanism

Subjective down: a sentinel marks an instance down if it does not respond within a timeout. Objective down: if a quorum of sentinels (more than half) agree, the instance is considered objectively down.

3.2.2 Election Rules

When a master is objectively down, sentinels elect a new master based on: disconnect time, slave-priority (lower is higher priority), offset (higher is better), and finally the smallest run‑id.

3.3 Split‑Brain Scenario

If network partition isolates the master, sentinels may promote a slave, resulting in two masters. After network recovery, the old master becomes a slave, which can cause data loss.

3.3.2 Split‑Brain Solutions

Configure min-replicas-to-write 1 and min-replicas-max-lag 5 so that writes are rejected when the required number of replicas is not reachable or lag exceeds 5 seconds, preventing data loss.

4. Sharding Cluster

4.1 Structure

A sharding cluster has multiple masters, each holding a subset of data, and each master may have multiple slaves. Masters monitor each other via ping; if a majority consider a master down, it is objectively down.

4.2 Routing Rules

Redis cluster uses 16384 hash slots. Each key is hashed (CRC16) and modulo 16384 to determine its slot, and the slot maps to a specific master.

4.3 Advantages and Disadvantages

Advantages: handles massive data, high availability, high concurrency. Disadvantages: complex maintenance, high network overhead, cannot use Lua scripts or transactions.

5. Interview Questions

5.1 What Redis clustering solutions exist?

Master‑slave replication, Sentinel mode, and Redis sharding cluster.

5.2 Explain master‑slave synchronization

Read‑write separation with one master and multiple slaves; the master writes data and propagates it to slaves.

5.3 Describe the master‑slave sync process

Two phases: full sync (initial RDB transfer plus backlog commands) and incremental sync (subsequent commands based on offset).

5.4 How to ensure high concurrency and high availability?

Deploy master‑slave replication together with Sentinel for automatic failover and client notification.

5.5 Which Redis deployment would you choose?

Master‑slave (1 master, 1 slave) plus Sentinel; avoid sharding due to maintenance complexity.

5.6 How to solve split‑brain in Redis cluster?

Set min-replicas-to-write and min-replicas-max-lag to reject writes when replication conditions are not met.

5.7 What is the purpose of a sharding cluster?

It solves massive data storage by distributing data across multiple masters, each possibly with slaves, and routes client requests to the appropriate node.

5.8 How does data storage and retrieval work in a sharding cluster?

Each key’s hash slot determines which master stores the key; the client is redirected to that master.