Designing a High‑Availability Redis Service with Sentinel

Redis is widely used as an in‑memory key‑value store for session data, caching, simple message queues, and pub/sub, but a single instance suffers from single‑point‑of‑failure risks.

To achieve high availability (HA), the article defines three failure types: a process crash on a node, an entire node outage, and a network partition between nodes.

The guiding principle is that the probability of multiple independent failures occurring simultaneously is negligible, so a system that tolerates brief single‑node failures can be considered HA.

Various HA solutions are examined:

Solution 1 – a single Redis server without Sentinel (suitable only for learning or personal projects, but vulnerable to any server or process failure).

Solution 2 – master‑slave replication with a single Sentinel instance monitoring both servers; this eliminates the master failure but introduces a new single point of failure in the Sentinel itself.

Solution 3 – master‑slave replication with two Sentinel instances; while clients can fall back to the remaining Sentinel, a network partition can prevent the remaining Sentinel from achieving the required 50% quorum, leaving the service unavailable.

Solution 4 – master‑slave replication with three Sentinel instances across three machines; this configuration tolerates any single process, single‑machine, or two‑machine network failure and continues to serve clients.

For even smoother client experience, the article suggests using a virtual IP (VIP) that always points to the current master; when a failover occurs, a callback script moves the VIP to the new master, allowing clients to connect to a single address as if it were a standalone Redis instance.

The conclusion emphasizes that while deploying a basic Redis service is simple, achieving true HA requires additional servers, multiple Sentinel processes, and monitoring tools such as Supervisor to automatically restart crashed processes.