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

Redis Sentinel

Sentinel Introduction

Sentinel is the official Redis high‑availability solution that can automatically fail over a master, monitor instances, and notify clients.

Key functions include Monitoring, Notification, Automatic failover, and Configuration provider.

Sentinel Configuration

Sentinel runs as a special‑mode Redis server. Example sentinel.conf:

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

Start with Redis 2.8+: redis-sentinel sentinel.conf After start, Sentinel:

Every 10 s sends INFO to the monitored master.

Every 1 s PINGs all Redis servers including other Sentinels.

Every 2 s publishes its view of master/slave status.

It is recommended to run at least three Sentinel instances and require two votes for a failover.

Three Ways to Receive Failover Messages

Script Notification

Configure a notification script executed on failover (max 60 s).

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

Configure a client reconfiguration script after failover.

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

Client Direct Subscription

Sentinel publishes events via Redis Pub/Sub. Clients subscribe to channels such as “+slave”. Message format:

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

Example:

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

Service‑Level Indirect Reception

Introduce an intermediate service that subscribes to Sentinel events and exposes an API for applications to receive callbacks, reducing coupling and improving scalability.

Application does not need to change when Sentinel is replaced.

Service can add watchdog threads for extra reliability.

Example API endpoint: http://127.0.0.1/redis/notify.api Service calls the API after detecting a state change:

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

Overall Design

The third method (service‑level indirect reception) is recommended. The diagram below illustrates the flow.

Conclusion

Various Sentinel notification types are documented in the official Redis docs. The author’s project uses the HRedis client (https://github.com/mushroomsir/HRedis). While ZooKeeper can be used for HA, Sentinel offers a low‑cost, extensible solution suitable for small teams.