Mastering Redis High Availability: Sentinel, Cluster, and Real‑World Architectures

Redis Overview

Redis is an open‑source, ANSI‑C written, in‑memory key‑value store that can persist data to disk and provides client libraries for many languages. Its design prioritises performance, making it one of the fastest NoSQL databases.

Why High Availability Matters

Modern internet services generate massive, diverse data at increasing speed, demanding both high throughput and continuous 24/7 availability. Rapid failover minimizes service loss during node or network failures.

Sentinel Principle

Before exploring HA solutions, the article explains Redis Sentinel (https://redis.io/topics/sentinel). Sentinel discovers masters via configuration, monitors them, exchanges hello messages, pings instances, and coordinates failover only after a quorum of Sentinels authorises it. It also updates configuration versions after a successful failover.

Discovery: Sentinels read the config to find the master and query its slaves via INFO.

Hello: Every second each Sentinel sends a hello containing its IP, port, and ID to the master and other Sentinels.

Subscription: Sentinels listen for hello messages from peers monitoring the same master.

Ping: Sentinels ping instances; if no reply within down-after-milliseconds, the instance is considered down.

Quorum: Failover starts only after a majority (quorum) of Sentinels grant permission.

Slave Promotion: The selected slave receives SLAVEOF NO ONE based on priority, offset and PID.

Config Update: The elected Sentinel broadcasts the new config‑epoch to all Sentinels.

Steps 1‑3 constitute automatic discovery, step 4 is health checking, steps 5‑7 handle failover and configuration propagation.

Redis High‑Availability Architectures

After Sentinel, the article lists common HA patterns, their advantages and drawbacks.

Sentinel + internal DNS + custom script

Sentinel + VIP + custom script

Client‑side direct connection to Sentinel port (JedisSentinelPool for Java, custom wrapper for PHP)

Sentinel + Keepalived/Haproxy

Master/Slave + Keepalived

Redis Cluster

Twemproxy

Codis

Sentinel + Internal DNS + Custom Script

Sentinel monitors masters; a script rewrites internal DNS records to point a service name to the current master. Advantages: sub‑second failover (≈10 s), fully scriptable, transparent to applications. Drawbacks: higher maintenance (≥3 machines), DNS latency, brief service interruption, unsuitable for external access.

Sentinel + VIP + Custom Script

Similar to the DNS solution but replaces DNS with a virtual IP that the script moves to the new master. Benefits: faster failover (≈5 s), scriptable, transparent. Drawbacks: higher maintenance, IP‑conflict risk, brief outage, not for external services.

Client‑Side Direct Sentinel Port

Clients connect to a Sentinel port, obtain the current master address, then talk directly to the master. Works for services that must be reachable from the Internet. Pros: quick fault detection, low DBA overhead. Cons: requires client support for Sentinel, open access to Sentinel and Redis nodes, and introduces application coupling.

Sentinel + Keepalived/Haproxy

Sentinel handles Redis master election while Keepalived moves a VIP. Provides sub‑second failover and application transparency. Cons: higher operational cost, split‑brain risk, brief outage during Sentinel failover.

Master/Slave + Keepalived

Uses native Redis replication with a VIP managed by Keepalived. Simple deployment, low cost, but requires custom scripts for master promotion and shares the same drawbacks as the previous pattern.

Redis Cluster

Introduced in Redis 3.0, the cluster shards keys into 16 384 slots across nodes, uses a peer‑to‑peer gossip protocol, and provides automatic failover. Advantages: all‑in‑one deployment, good performance, automatic failover, official support. Drawbacks: newer ecosystem, limited multi‑key operations, client‑side slot cache required, manual resharding.

Twemproxy

Twemproxy (nutcracker) is a stateless proxy that hashes keys and forwards requests to the appropriate Redis instance. It is mature and easy to deploy but adds latency, can become a bottleneck, and makes scaling difficult.

Codis

Codis, open‑sourced by 豌豆荚, adds a ZooKeeper‑backed routing layer, a stateless proxy, and a modified Redis with slot support. It offers a web UI and easier scaling but introduces extra components, performance overhead, and diverges from upstream Redis.

Best Practices

The article recommends the DNS‑based and VIP‑based Sentinel solutions as primary choices and provides operational tips: run Sentinel on ≥5 nodes, share a Sentinel cluster across services, allocate distinct port ranges, implement custom scripts in Python using paramiko, disable UseDNS and GSSAPIAuthentication in SSH, fork alert processes, and keep failover under 15 seconds.