High‑Availability Strategies for Redis: Sentinel Service Discovery, VIP Binding, Keepalived VRRP, and Proxy Approaches

Redis is a high‑performance in‑memory database widely used for leaderboards, rating services, and more; beyond data types and performance, high availability is crucial, and Redis Sentinel provides automatic failover monitoring.

When a failover occurs, clients need to discover the new master address.

Method 1: Using Redis Sentinel Service Discovery

Sentinel offers a service‑discovery command SENTINEL get-master-addr-by-name that returns the current master address, updating automatically after failover.

Many smart Redis client libraries implement this mechanism. By providing a list of Sentinel addresses, the client queries Sentinel for the latest master and connects accordingly. Example with Jedis:

sentinels.add(new HostAndPort("192.168.0.31",26379).toString());
sentinels.add(new HostAndPort("192.168.0.32",26379).toString());
sentinels.add(new HostAndPort("192.168.0.33",26379).toString());
pool = new JedisSentinelPool(masterName, sentinels, config, TIMEOUT,password);
...
// Get connection:
Jedis jedis = pool.getResource();
try {
jedis.set("hello", "jedis");
} finally {
jedis.close();
}

Jedis maintains the latest master address in memory. Other clients may query Sentinel on each connection, incurring two requests per operation, which is less efficient.

Method 2: Binding a VIP

A virtual IP (VIP) is kept bound to the current master. Clients simply connect to the VIP, oblivious to failover. Sentinel can invoke a client‑reconfig‑script after a failover to re‑bind the VIP to the new master.

VIP binding does not rely on client intelligence and is flexible, though it may not work for external network access; DNS‑based solutions can replace VIP for internet‑facing scenarios.

Method 3: Using keepalived VRRP

Similar to Method 2, keepalived implements VRRP to manage the VIP, eliminating the need for Sentinel‑triggered scripts.

Method 4: Middleware Proxy

Public‑cloud Redis services often expose a proxy address that forwards traffic to the appropriate master or slave. Implementing such a proxy requires development effort and its own HA, but it can provide advanced features (e.g., Alibaba Cloud Redis Proxy) such as write routing to master, weighted read routing, and automatic isolation of faulty read replicas.

Cluster Architecture – Method 1: Request Redirection

Clients may send a request to any node; if the key’s slot resides elsewhere, the node returns a MOVED response with the correct address, prompting the client to retry. Tools like redis-cli handle this automatically, though it may double the request count.

Cluster Architecture – Method 2: Local Cache of Slots List

Smart clients (e.g., JedisCluster ) fetch the slot‑to‑node mapping at startup and cache it locally, sending requests directly to the correct node. When slots migrate, the client updates its cache upon receiving an error, minimizing performance impact.

Cluster Architecture – Method 3: Middleware Proxy

A generic middleware proxy can also handle slot routing for clients that lack built‑in intelligence, though its implementation cost and benefits must be weighed.

Keywords: #redis#