Master‑Slave, Sentinel, and Sharding: Complete Guide to Redis Cluster Architectures

1. Redis cluster solutions

Redis provides three cluster solutions (generally a node does not exceed 10 GB memory):

Master‑slave replication – solves high concurrency.

Sentinel mode – solves high availability.

Sharding cluster.

2. Master‑slave replication (data sync)

2.1 Definition

Master‑slave replication copies data from one Redis server (master) to other servers (slaves). The replication is one‑way, from master to slave.

By default each Redis instance is a master; a master can have multiple slaves, but a slave has only one master.

Architecture diagram:

2.2 How to set up master‑slave

In master‑slave mode, the master handles read/write, slaves usually read‑only; writes on a slave cause an error. Data is synchronized to keep consistency.

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

① Basic configuration: install Redis on all three nodes, copy A’s config to B and C, then start Redis. ② Enable replication using replicaof (or slaveof ) command; can be temporary (via redis-cli) or permanent (in redis.conf).

2.3 Replication synchronization principles

2.3.1 Full synchronization

During full sync, master performs a BGSAVE to generate an RDB file and sends it to the slave. Writes occurring during BGSAVE are logged in repl_backlog; after sending the RDB, the backlog commands are also sent to the slave to ensure consistency. Q: How does master know a slave is connecting for the first time? A: By comparing Replication ID (replid) and offset. A new slave has a different replid, prompting a full sync.

2.3.2 Incremental synchronization

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

2.4 Pros and cons of master‑slave

Pros: solves read‑heavy high concurrency.

Cons: does not guarantee high availability; Sentinel is needed.

3. Sentinel mode

3.1 Purpose

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

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

3.2 Sentinel monitoring (heartbeat) and election rules

3.2.1 Heartbeat mechanism

Sentinel sends PING to each instance every second. Subjective down: a sentinel marks an instance down if it does not respond in time. Objective down: if a quorum of sentinels (majority) agree, the instance is objectively down.

3.2.2 Election rules

When a master is objectively down, Sentinels elect a new master based on: Longest disconnection time (exclude if exceeds threshold). Lowest slave‑priority value. If priorities equal, highest offset (most up‑to‑date). Finally, smallest run‑id.

3.3 Split‑brain scenario in Sentinel

If network partition isolates the original 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.1 Split‑brain process

Explanation of the process and data loss risk.

3.3.2 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

Features: Multiple masters each holding different data; each master can have multiple slaves, enabling massive data storage and high read/write concurrency. No Sentinel needed; masters ping each other, and a majority can mark a master down. Clients can connect to any node; requests are routed to the correct master based on hash slots.

4.2 Routing rules

Redis cluster uses 16384 hash slots; each key’s CRC16 modulo 16384 determines its slot, and each master is responsible for a subset of slots.

4.3 Pros and cons

Pros: solves massive data storage, high availability, high concurrency.

Cons: complex maintenance, high network bandwidth for heartbeats, cannot use Lua scripts or transactions.

5. Related interview questions

5.1 What Redis cluster solutions exist?

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

5.2 Explain master‑slave sync

Read‑write separation with one master and multiple slaves; master writes then syncs to slaves.

5.3 Describe the master‑slave sync process

Two phases: full sync (RDB transfer and backlog replay) and incremental sync (offset‑based command replay).

5.4 How to ensure Redis high concurrency and high availability?

Deploy master‑slave with Sentinel for automatic failover and client discovery.

5.5 Which Redis deployment would you choose?

Master‑slave (1 master, 1 slave) with Sentinel; avoid sharding unless needed.

5.6 How to handle split‑brain in Redis cluster?

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

5.7 What is the purpose of sharding cluster?

Store massive data by distributing keys across multiple masters, each possibly with slaves, and route client requests accordingly.

5.8 How are data stored and read in a sharding cluster?

Keys are mapped to one of 16384 hash slots via CRC16; the slot determines the responsible master node.