Building a High‑Availability Redis Service with Sentinel

In‑memory Redis is widely used in web development for session storage, caching hot data, simple message queues, and pub/sub, often provided as a foundational service by large internet companies.

When offering such a service, high availability is essential; the system must continue operating despite various failures, such as a single process crash, an entire server outage, or network partition between nodes.

Typical failure scenarios include:

Node process unexpectedly stops.

Whole server goes down.

Communication between two nodes is broken.

The design principle is to tolerate single‑point failures, assuming multiple simultaneous failures are negligible.

Common HA solutions for Redis include Keepalived, Codis, Twemproxy, and Redis Sentinel; for modest data volumes the article selects the official Redis Sentinel.

Redis Sentinel monitors Redis instances and automatically promotes a replica to master when the primary fails, providing transparent failover for clients.

Solution 1: Single‑node Redis (no Sentinel)

This setup is simple but suffers from a single point of failure; if the Redis process or its host crashes, the service becomes unavailable and data may be lost without persistence.

Solution 2: Master‑Slave with a single Sentinel

A master and a slave are deployed, and one Sentinel monitors them; if the master fails, the slave is promoted. However, the Sentinel itself is a single point of failure, so this configuration does not achieve true HA.

Solution 3: Master‑Slave with two Sentinels

Adding a second Sentinel allows clients to query either instance, but quorum requires a majority of Sentinels to be reachable; with only two Sentinels, a network partition can leave the system unable to elect a new master, breaking HA.

Solution 4: Master‑Slave with three Sentinels

Introducing a third Sentinel on a separate server ensures that any single process, server, or pairwise network failure still leaves a majority of Sentinels, allowing automatic failover and maintaining service availability.

For client simplicity, a virtual IP (VIP) can be assigned to the current master; when failover occurs, a script moves the VIP to the new master, letting clients continue using a single IP and port as if it were a standalone Redis instance.

In conclusion, while a single Redis instance is easy to run, achieving high availability requires additional servers, multiple Sentinel processes, and supervision tools (e.g., Supervisor) to monitor and restart processes, ensuring the service remains operational even during rare failure events.