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

In‑memory Redis is widely used for session storage, hot‑data caching, simple message queues, and Pub/Sub, but any basic service provider must answer whether the service is highly available.

High availability means the service continues to operate despite failures, or recovers quickly. Typical failures include a single process crash, an entire node outage, or loss of communication between nodes.

The basic principle is that multiple low‑probability failures occurring simultaneously can be ignored; the system should tolerate single‑point failures.

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

Solution 1: Single‑instance Redis without Sentinel

This simple setup works for personal projects but suffers from a single point of failure; if the Redis process or its host crashes, the service becomes unavailable and data may be lost without persistence.

Solution 2: Master‑Slave with a single Sentinel

Two Redis instances (master and slave) are monitored by one Sentinel process, which promotes the slave when the master fails. However, the Sentinel itself is a single point of failure, so this configuration does not achieve true HA.

Solution 3: Master‑Slave with two Sentinels

Running two Sentinel processes allows clients to query either one for master discovery. If one Sentinel fails, the other can still respond. Yet Redis requires a majority (over 50%) of Sentinels to agree on a failover; with only two Sentinels, a network partition can leave only one reachable, preventing promotion and breaking HA.

Solution 4: Master‑Slave with three Sentinels (final architecture)

Adding a third Sentinel on a third server provides a majority even if one node or its network fails, ensuring continuous service. Optionally, a third Redis instance can be added for additional replication.

When a node loses all communication, the remaining Sentinels promote the surviving slave to master, briefly resulting in two masters. To avoid data inconsistency, configure Redis with min-slaves-to-write and min-slaves-max-lag so a slave stops accepting writes if it cannot confirm enough replicas.

For client simplicity, a virtual IP (VIP) can be assigned to the current master. A failover script moves the VIP to the new master, allowing clients to connect to a single IP as if using a standalone Redis instance.

In practice, the author also uses Supervisor to monitor processes and automatically restart them on failure.