Mastering Redis Sentinel: Build a Cost‑Effective High‑Availability Solution

Redis high‑availability solutions often use keepalived or Zookeeper, but this article focuses on the official Redis Sentinel approach.

Redis Sentinel

Sentinel Introduction

Sentinel is Redis's official high‑availability solution that can automatically perform failover, reducing manual intervention, and provides notifications to clients so they can adapt to server status changes.

Key Sentinel functions include:

Monitoring: continuously checks the health of master and slave instances.

Notification: alerts administrators or scripts via API when a Redis instance fails.

Automatic failover: promotes a slave to master when the current master goes down and reconfigures other slaves.

Configuration provider: clients query Sentinel for the current master address and receive updates after failover.

Sentinel Configuration

Sentinel runs as a Redis server in a special mode; its behavior is defined in sentinel.conf:

// [monitor name] [ip] [port] [quorum]
sentinel monitor mymaster 127.0.0.1 6379 2
// [down‑after‑milliseconds]
sentinel down-after-milliseconds mymaster 60000
// [failover‑timeout]
sentinel failover-timeout mymaster 180000
// [parallel‑syncs]
sentinel parallel-syncs mymaster 1

Sentinel requires Redis 2.8+ and is started with: redis-sentinel sentinel.conf After startup, Sentinel:

Every 10 seconds sends an INFO command to the monitored master to obtain its status.

Every 1 second PINGs all Redis servers (including other sentinels) to check liveness.

Every 2 seconds broadcasts messages containing current sentinel and master information to all monitored masters and slaves.

It is recommended to run at least three Sentinel instances and configure a quorum of two (or three of five, etc.) to tolerate failures.

Three Ways to Receive Failover Messages

When a Redis instance fails, Sentinel elects a new master via a Raft‑like algorithm. Failover events can be obtained through Sentinel’s API.

Script Reception

A notification script can be specified to inform administrators during failover.

The script’s execution time is limited to 60 seconds.

sentinel notification-script mymaster /var/redis/notify.sh

After failover, a client reconfiguration script can be set.

sentinel client-reconfig-script mymaster /var/redis/notifyReconfig.sh

Client Direct Reception

Sentinel publishes failover events via Redis Pub/Sub; clients subscribe to channels such as +slave to receive messages. The message format is:

<instance-type> <name> <ip> <port> @ <master-name> <master-ip> <master-port>

Example:

*          // subscribe all events
-sdown     // message type
slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381

Java subscription example:

using (RedisSentinel rs = new RedisSentinel(CurrentNode.Host, CurrentNode.Port))
{
    var redisPubSub = new RedisPubSub(node.Host, node.Port);
    redisPubSub.OnMessage += OnMessage;
    redisPubSub.OnSuccess += (msg) => {};
    redisPubSub.OnUnSubscribe += (obj) => {};
    redisPubSub.OnError = (exception) => {};
    redisPubSub.PSubscribe("*");
}

Service Indirect Reception

This method adds a dedicated service that subscribes to Sentinel and exposes an API for applications to receive callbacks, reducing coupling and improving performance.

Reduces the chance of application‑side listening failures.

Turns the application from an active to a passive participant.

Improves performance by replacing polling with callbacks.

Provides higher extensibility as an independent service.

Example workflow:

Application provides a callback API at http://127.0.0.1/redis/notify.api. http://127.0.0.1/redis/notify.api The monitoring service detects status changes and calls the API:

httprequest.post("http://127.0.0/redis/notify.api");

Overall Design

The third method is recommended; the overall flow diagram is shown below.

Summary

All Sentinel notification types are documented officially; the Redis client used in the project is available on GitHub.

https://github.com/mushroomsir/HRedis

This article shares practical experience of implementing Redis high availability, recommending Zookeeper when resources permit, otherwise using Sentinel as a low‑cost, extensible solution.

There is no best architecture, only the most suitable one.

http://redis.io/topics/sentinel