Designing a High‑Availability Redis Service with Sentinel

Redis is a widely used in‑memory key‑value store for sessions, caching, simple queues, and pub/sub, but a single Redis instance suffers from single‑point‑of‑failure risks, prompting the need for high‑availability solutions.

The author defines high availability as the ability of the service to continue operating or recover quickly after various failures, enumerating three typical anomalies: a Redis process crash on a node, an entire node failure, and network partition between nodes.

Several HA designs are evaluated:

Option 1 – Single Redis server without Sentinel: simple but vulnerable to any node or process failure.

Option 2 – Master‑slave replication with a single Sentinel instance: adds failover capability but the Sentinel itself becomes a single point of failure.

Option 3 – Master‑slave replication with two Sentinel instances: improves Sentinel redundancy but still cannot guarantee failover when a whole node goes down because a majority of Sentinels is required for election.

Option 4 – Master‑slave replication with three Sentinel instances on three machines: the chosen solution; it tolerates single‑process, single‑machine, or two‑machine network failures, ensuring continuous service.

The article also suggests optionally adding a third Redis server (one master, two slaves) for extra data redundancy, and discusses using virtual IP (VIP) to present a single address to clients, automatically moving the VIP during master promotion.

Finally, the author notes that while building a basic service is easy, achieving high availability adds complexity, requiring additional servers, multiple Sentinel processes, and supervision tools like Supervisor to monitor and restart processes.