Understanding Redis High Availability: Master‑Slave, Sentinel, and Cluster Explained

1. Master‑Slave Mode

Redis single‑node deployments suffer from single‑point failures; deploying the same service on multiple machines ensures availability, but the master‑slave model still stores full data on each node.

In master‑slave replication, a master database automatically synchronizes updates to one or more slave databases, providing read/write separation and data backup.

Advantages and Disadvantages

Advantages: read/write separation, data backup, multiple replicas.

Disadvantages: no automatic failover; when the master fails, manual promotion of a slave is required using commands such as SLAVE NO ONE and SLAVEOF.

2. Sentinel Mode

Sentinel monitors all master and slave instances, automatically promoting a slave to master when the original master crashes, thus eliminating manual intervention.

Sentinel configuration uses the command: sentinel monitor master-name ip port quorum Sentinel processes communicate via the _sentinel_:hello channel to share monitoring data.

Functions

Monitoring server health by sending periodic commands.

Automatic failover: when a master is considered subjectively down, Sentinel asks other Sentinels; if a quorum agrees, the master is marked objectively down and a new master is elected.

Failover Steps

Select a leader Sentinel.

The leader chooses the slave with the highest slave‑priority (or the most recent replication offset, then the smallest run ID) as the new master.

Promote the chosen slave with SLAVE NO ONE and reconfigure other slaves to follow the new master.

Pros and Cons

Pros: automatic master promotion without human intervention.

Cons: still a single‑master write bottleneck, each node stores full data (wasting memory), writes are paused during election, and true data sharding is not achieved.

3. Industry Redis Cluster Solutions

Before Redis 3.0 (released in 2015) many companies built their own sharding solutions to overcome storage bottlenecks.

Client‑Side Sharding

Clients embed sharding logic (e.g., Jedis ShardedJedis) and use consistent hashing (often MurmurHash) to route keys to specific Redis instances.

Advantages

Full control over routing, linear scalability, and no dependency on external middleware.

Disadvantages

Requires code changes in every client language; adding or removing nodes forces manual rebalancing across all clients.

Proxy Sharding (Twemproxy)

Twemproxy, an open‑source Redis proxy from Twitter, sits between clients and Redis instances, handling routing and aggregating responses.

Pros

Clients connect to Twemproxy just like a single Redis instance; no code changes needed.

Automatically removes invalid Redis instances and reduces the number of client‑to‑Redis connections.

Cons

Additional latency because every request passes through the proxy.

Lacks a friendly management UI and makes smooth scaling difficult.

Codis

Codis introduces a Redis Server Group abstraction and a slot‑based sharding scheme (1024 slots). Each group contains a master and one or more slaves for high availability.

When a master fails, Codis‑ha can automatically promote a slave. Slots are assigned using crc32(key)%1024. Administrators can manually reassign slots with the Codisconfig tool or automatically rebalance slots based on memory usage.

Rebalancing example:

4. Redis Cluster

Redis Cluster, available since Redis 3.0, provides true server‑side sharding with multiple masters and replicas, eliminating the single‑master write bottleneck.

Decentralized P2P architecture; recommended deployment includes at least three master nodes (commonly 3 masters + 3 slaves).

Clients connect to any node; the cluster routes requests based on 16384 hash slots.

Each master owns a subset of slots; replicas provide high availability.

Redis Cluster is ideal for massive data, high concurrency, and high‑availability scenarios, offering better performance and resilience than Sentinel‑only setups.