Designing a High‑Availability Redis Service with Sentinel

Redis, as an in‑memory key‑value store, is widely used for session storage, caching hot data, simple message queues, and Pub/Sub, but a single instance suffers from single‑point failures.

High availability is defined as the ability to continue serving requests despite various failures, such as a process crash, a whole node shutdown, or loss of communication between nodes.

Several solutions exist: Keepalived, Codis, Twemproxy, and the official Redis Sentinel. For modest data volumes, Sentinel is chosen over clustering solutions.

Solution 1: Single‑node Redis without Sentinel – simple but vulnerable to process or server failures, leading to service downtime and possible data loss without persistence.

Solution 2: Master‑slave replication with a single Sentinel – adds a backup slave and a Sentinel to monitor the master, but the Sentinel itself becomes a single point of failure.

Solution 3: Master‑slave replication with two Sentinels – adds a second Sentinel for failover, yet if an entire server goes down, only one Sentinel remains reachable, which is insufficient for quorum‑based failover.

Solution 4: Master‑slave replication with three Sentinels – introduces a third server running an additional Sentinel, achieving quorum even when one server fails or network partitions occur, thus providing true high availability.

To improve usability, a virtual IP (VIP) can be used so clients connect to a single address; the VIP is moved to the current master during failover, making the high‑availability setup transparent to applications.

In conclusion, while deploying a basic Redis instance is easy, achieving high availability requires extra servers, multiple Sentinel processes, and supervision tools to automatically restart failed processes.