Designing a High‑Availability Redis Service with Sentinel

Redis is a widely used in‑memory key‑value store for session storage, caching hot data, simple message queues, and pub/sub, but providing high availability (HA) is essential for production services.

HA is defined as the ability to continue serving despite various failures, such as a single process crash, an entire node outage, or network partition between nodes.

Among many HA solutions (Keepalived, Codis, Twemproxy, Redis Sentinel), the author chose the official Redis Sentinel for a modest data volume.

Scheme 1: Single‑instance Redis without Sentinel – simple but suffers from a single point of failure; if the process or server stops, the service is unavailable and data may be lost.

Scheme 2: Master‑slave 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, so true HA is not achieved.

Scheme 3: Master‑slave with two Sentinels – runs two Sentinel instances for failover, yet quorum requirements (more than 50% Sentinels reachable) prevent automatic failover when one node is down, still lacking HA.

Scheme 4: Master‑slave with three Sentinels – adds a third Sentinel on a third server, achieving HA for single‑process, single‑machine, or two‑machine network failures; optional third Redis server can further improve redundancy.

To simplify client usage, a virtual IP (VIP) can be assigned to the current master; when failover occurs, a script moves the VIP to the new master, allowing clients to connect to a single IP/port as if using a standalone Redis.

The final architecture uses three servers, three Sentinel processes, and one slave, providing robust HA while keeping resource consumption modest; supervision tools like Supervisor monitor processes for automatic restart.

Overall, building a highly available Redis service involves understanding failure modes, selecting appropriate Sentinel deployment, and optionally using VIPs to hide complexity from clients.