Mastering Redis High Availability: From Master‑Slave to Sentinel and Cluster

In service development, a single server can become a single point of failure; deploying services on multiple machines provides high availability. Redis also faces this issue. The basic master‑slave replication can automatically copy data from a master to slaves, but manual intervention is required when the master fails.

Master‑Slave Mode

Redis single node persists data via RDB/AOF, but all data resides on one server, leading to potential data loss on hardware failure and I/O bottlenecks because reads and writes share the same node. Replication creates one master and multiple slaves, allowing read‑write separation and data backup.

The master can have many slaves, and slaves can be cascaded.

Advantages and Disadvantages

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

Disadvantages: no automatic failover; when the master crashes, manual promotion of a slave is required.

Manual failover commands:

Use SLAVEOF NO ONE on a slave to promote it.

Restart the crashed master and run SLAVEOF to make it a slave of the new master.

Sentinel Mode

Sentinel, introduced in Redis 2.6 and stabilized in 2.8, adds an automatic election mechanism that promotes a slave to master when the master fails, without human intervention.

Multiple sentinel processes monitor each other and the master‑slave topology, forming a peer‑to‑peer monitoring network.

(1) Functions of Sentinel

Monitors server health, performs automatic failover by promoting a slave, and notifies other slaves via Pub/Sub to reconfigure.

(2) Implementation Principle

Sentinel reads a configuration file to discover masters to monitor.

sentinel monitor master-name ip port quorum
# master-name is the name of the master
# ip and port are the master's address
# quorum is the number of sentinels that must agree before failover

Each sentinel opens two connections to the master: one subscribes to _sentinel:hello channel, the other periodically sends INFO commands.

(3) Subjective and Objective Down

If a sentinel does not receive a ping reply within down‑after‑milliseconds, it marks the node as subjectively down. When a quorum of sentinels agree, the node is considered objectively down and failover proceeds.

(4) Pros and Cons of Sentinel

Pros

Provides automatic failover for master failures.

Cons

Still a single‑write master, so write throughput is limited by one node.

All nodes store full data, wasting memory and impacting performance at large scale.

During election, writes are blocked until a new master is chosen.

Redis Cluster Solutions by Major Companies

Before Redis 3.0 (released 2015), companies built their own sharding solutions such as client‑side sharding, Twemproxy, and Codis.

(1) Client‑Side Sharding

Clients implement routing logic (e.g., consistent hashing) to distribute keys across multiple Redis instances. This approach offers full control but requires manual reconfiguration when the cluster topology changes.

Advantages

Consistent hashing enables linear scalability without a central coordinator.

Disadvantages

Static sharding requires manual adjustment of the client when adding or removing instances.

Higher operational cost and duplicated routing logic across different language clients.

All clients must be updated when topology changes.

(2) Proxy Sharding (Twemproxy)

Twemproxy acts as a middleware proxy; clients connect to it, and it forwards requests to the appropriate Redis instance based on routing rules.

Advantages

No code changes required for clients.

Automatically removes dead Redis instances.

Reduces the number of client‑to‑Redis connections.

Disadvantages

Additional latency due to proxy layer.

Lacks a friendly monitoring UI.

Cannot smoothly scale out/in; adding instances requires manual effort.

(3) Codis

Codis, an open‑source proxy written in Go and C, introduces Redis Server Groups with a primary and one or more replicas, supporting smooth scaling of groups.

Codis uses a fixed number of 1024 slots; keys are mapped to slots via crc32(key)%1024. Slots are assigned to server groups, and rebalancing can be performed manually or automatically.

When a new server group is added, slots are redistributed either via the Codis management tool or its rebalance feature.

Redis Cluster

Redis Cluster, introduced in Redis 3.0, provides true sharding and multi‑master architecture, eliminating the memory waste of sentinel mode. Each node holds a subset of the keyspace (hash slots) and communicates with peers via a PING‑PONG protocol.

Official recommendations suggest at least three master nodes, preferably a 3‑master‑3‑slave topology. Cluster characteristics include:

Fully decentralized, multi‑master‑multi‑slave topology.

Clients connect directly to any node; the cluster routes requests internally.

Each master manages a range of hash slots; all nodes have a full slot map.

Redis Cluster is suitable for massive data, high concurrency, and high availability scenarios, offering better performance and reliability than sentinel.