Redis High Availability: Master‑Slave, Sentinel, and Cluster Solutions

In service development, a single machine creates a single point of failure; deploying services across multiple machines ensures high availability.

Redis also suffers from single‑node failures. Master‑slave replication mitigates this but requires manual promotion of a slave when the master crashes.

Sentinel mode automates failover by monitoring masters and slaves, electing a new master, and notifying other nodes without manual intervention.

1. Master‑Slave Mode

The master‑slave architecture provides read‑write separation, data backup, and multiple replicas, improving efficiency. However, it lacks automatic fault tolerance; when the master fails, a slave must be manually promoted using commands such as SLAVE NO ONE or SLAVEOF.

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

Disadvantages: no automatic failover, manual promotion required.

2. Sentinel Mode

Sentinel adds automatic monitoring and failover to the master‑slave setup. It continuously checks the health of master and slave nodes, participates in leader election, and promotes a slave to master when the original master is down.

Sentinel distinguishes between subjective and objective down states, uses a quorum of sentinels to confirm failures, and follows a defined failover procedure (select leader sentinel, choose the highest‑priority slave, promote it, and reconfigure other slaves).

sentinel monitor master-name ip port quorum
# master-name is the name of the master
# ip and port are the master address
# quorum is the number of sentinels required for failover

Sentinels periodically send INFO commands to masters and slaves, publish their status on the _sentinel_:hello channel, and ping nodes every second to detect failures.

3. Industry Redis Cluster Solutions

Before Redis 3.0 introduced native clustering, many companies built their own sharding solutions, including client‑side sharding, proxy‑based sharding, and Codis.

Client‑Side Sharding

Clients implement consistent hashing (e.g., MurmurHash) to route keys to specific Redis instances. Libraries such as Jedis provide a ShardedJedis implementation.

Proxy‑Based Sharding (Twemproxy)

Twemproxy acts as a middleware layer: clients connect to Twemproxy, which routes requests to the appropriate Redis instance and aggregates responses, reducing the number of client‑to‑Redis connections.

Pros: no code changes for clients, automatic removal of failed instances, connection pooling.

Cons: added latency, lack of a friendly monitoring UI, difficult smooth scaling.

Codis

Codis introduces Redis Server Group concepts and pre‑allocates 1024 hash slots. Keys are mapped to slots using crc32(key)%1024. Codis provides tools such as Codis‑ha for automatic failover and a rebalance command for slot migration, enabling smooth scaling.

4. Redis Cluster

Redis Cluster offers native sharding with multiple masters and replicas, a fully decentralized peer‑to‑peer architecture, and slot‑based key distribution. Clients connect to any node; the cluster routes requests to the node owning the relevant slot.

Decentralized multi‑master/multi‑replica design.

Clients need only one reachable node; the cluster handles routing.

Each master owns a subset of 16384 hash slots, and all nodes maintain full slot metadata.

Cluster is recommended for scenarios with massive data volumes, high concurrency, and strict high‑availability requirements, while Sentinel remains sufficient for smaller deployments.