How to Build a Highly Available Redis Service with Sentinel and Virtual IP

Redis is widely used as an in‑memory key‑value store for sessions, caching, simple queues, and pub/sub. When providing Redis as a shared service, callers ask about high availability (HA). This article outlines the author’s experience building a small HA Redis setup using Redis Sentinel.

Defining HA and failure scenarios

HA means the service continues to operate after various failures: a single Redis process crash, an entire node failure, or loss of communication between nodes. The design assumes that multiple independent failures occurring simultaneously are extremely unlikely.

Available HA solutions

Common approaches include Keepalived, Codis, Twemproxy, and Redis Sentinel. For modest data volumes the author chose the official Redis Sentinel solution.

Solution 1 – Single Redis instance (no Sentinel)

A single Redis server provides no redundancy; if the process or host fails, the service and any non‑persistent data are lost.

Solution 2 – Master‑slave with a single Sentinel

Two Redis instances (master and slave) plus one Sentinel monitor them. Clients query Sentinel for the current master. However, the single Sentinel itself is a single point of failure, so true HA is not achieved.

Solution 3 – Master‑slave with two Sentinels

Running two Sentinel processes allows clients to fall back to the other if one fails. Yet if an entire node goes down, only one Sentinel remains reachable, which is insufficient because Sentinel requires a majority (>50%) to elect a new master, leaving the service unavailable.

Solution 4 – Master‑slave with three Sentinels (final architecture)

Adding a third server with an additional Sentinel gives three Sentinels monitoring two Redis instances. This configuration tolerates any single node failure, any single Sentinel failure, or a network partition between two nodes, maintaining service availability.

Optionally a third Redis instance can be added for extra redundancy, but too many slaves increase replication lag.

When a node loses network connectivity, the remaining Sentinels can promote the slave to master. To avoid split‑brain writes during a partition, Redis can be configured with min‑slaves‑to‑write and min‑slaves‑max‑lag so that a master stops accepting writes if it cannot reach enough slaves.

Usability – Making Sentinel transparent to clients

Clients normally need a Sentinel‑aware library and multiple Sentinel addresses. To keep the client experience identical to a single‑node Redis, a virtual IP (VIP) can be assigned to the current master. A failover script moves the VIP to the new master, so clients continue to connect to the same IP and port.

Conclusion

Building a basic Redis service is easy, but achieving HA requires extra nodes, multiple Sentinel processes, and supervision (e.g., Supervisor) to restart crashed processes. The three‑Sentinel design provides robust HA while keeping client configuration simple.