Mastering Redis: From Master‑Slave to Sentinel and Cluster Configurations

Redis Cluster Modes Overview

Redis supports three distinct clustering modes: master‑slave, Sentinel, and Cluster, each suited for different application scenarios.

Master‑Slave Mode

In the initial stage, Redis uses master‑slave replication where the master handles writes and slaves handle reads and backups. Manual promotion of a slave is required when the master fails, resulting in low automation.

Sentinel Mode

Sentinel adds high availability by monitoring master health and automatically electing a slave as the new master upon failure, improving stability and automation. However, it is limited by memory and write performance of a single node.

Cluster Mode

Cluster mode, introduced after Redis 3.x, uses data sharding and horizontal scaling across multiple nodes, enhancing memory utilization and write throughput for large‑scale workloads.

Feature/Config          Redis Master‑Slave          Redis Sentinel          Redis Cluster
Main Purpose            Data backup & read/write split  High availability & automatic failover  High concurrency & data distribution
Architecture            One master + many slaves       Monitor master‑slave and auto‑switch  Multiple masters, data sharding
Data Replication         Master → slave                Monitor & manage master‑slave replication  Each master manages its own dataset
Failover Mechanism       Manual or Sentinel auto‑switch  Automatic failover  Automatic node failure handling
Scalability              Limited, depends on master    Adds HA to master‑slave  High, due to distributed processing
Use Cases               Data backup & read scaling    Critical applications requiring HA  Large‑scale applications demanding high performance
Setup Complexity         Simple                        Moderate, requires sentinel config  Complex, needs data partition planning

Master‑Slave Replication Details

Master read/write capability : The master processes all writes and can also handle reads, synchronizing changes to all slaves in real time.

Unidirectional data flow : Data flows only from master to slaves, ensuring consistency.

Slave read‑only nature : Slaves are typically configured as read‑only to offload read traffic.

Master‑slave relationship : One master can have multiple slaves, providing redundancy and load distribution.

Slave fault tolerance : Failure of a slave has minimal impact; remaining slaves continue serving reads.

Master failure impact : Writes pause while the master is down, but slaves keep serving reads.

Handling master failure : Requires external solutions like Redis Sentinel or Redis Cluster to promote a new master.

PSYNC Working Principle

PSYNC is the core command for synchronizing data between a slave and its master.

Startup or reconnection check : The slave determines if it has ever synchronized with the master.

First‑time sync : The slave sends PSYNC -1 to request a full data copy.

Reconnection handling : A previously synced slave sends PSYNC <runid> <offset> where runid is the master’s ID and offset is the last processed byte.

Master response : If runid matches and offset is within the replication backlog, the master replies CONTINUE and streams missed writes.

Full sync trigger : Mismatched runid or out‑of‑range offset causes the master to issue FULLRESYNC <runid> <offset>.

Replication backlog role : The master stores recent write commands with a global offset, allowing slaves to perform incremental sync after reconnection.

Data consistency guarantee : PSYNC enables slaves to recover from network interruptions while keeping data consistent.

Redis Master‑Slave Environment Setup

Configuration files define master and slave settings, including bind address, ports, memory limits, persistence, and logging.

# Master configuration (redis.conf)
bind 0.0.0.0
protected-mode no
port 6380
maxmemory 30720mb
maxmemory-policy allkeys-lru
tcp-backlog 2048
timeout 0
tcp-keepalive 60
loglevel notice
dir E:\redis\data
save 900 1
save 300 10
save 60 10000
notify-keyspace-events ""
maxclients 1000000
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
lua-time-limit 5000
slowlog-log-slower-than 10000
slowlog-max-len 128
replicaof 10.41.170.130 6380
daemonize yes
pidfile E:\redis\redis-cluster\redis_100.pid
logfile E:\redis\redis-cluster\redis_100.log

# Slave configuration (redis.conf)
port 6381
replicaof 10.41.170.130 6380

Sentinel Mode Setup

Create sentinel.conf with the following core settings:

# Sentinel instance
port 26380
bind 0.0.0.0
sentinel monitor ebgmaster 10.41.170.130 6380 2
#sentinel auth-pass ebgmaster admin
sentinel down-after-milliseconds ebgmaster 5000
sentinel failover-timeout ebgmaster 15000
sentinel config-epoch ebgmaster 2
sentinel leader-epoch ebgmaster 2
daemonize yes
pidfile E:\redis\redis-cluster\sentinel_130.pid
logfile E:\redis\redis-cluster\sentinel_130.log

Start Sentinel with redis-server sentinel.conf --sentinel (Windows) or ./redis-sentinel sentinel.conf (Linux).

Cluster Mode Deployment

Configure each node with cluster-enabled yes and related settings.

# Example node configuration
bind 0.0.0.0
protected-mode no
port 6381
cluster-enabled yes
cluster-node-timeout 5000
cluster-config-file nodes-6381.conf
pidfile "E:\ebgsd\redis\6381\redis-cluster\redis_6381.pid"
logfile "E:\ebgsd\redis\6381\redis-cluster\redis_6381.log"
dir "E:\ebgsd\redis\6381\data"
maxmemory 80gb
maxmemory-policy allkeys-lru
timeout 0
tcp-keepalive 60
loglevel notice
save 900 1
save 300 10
save 60 10000
notify-keyspace-events ""
maxclients 1000000
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
daemonize yes

Create the cluster with:

redis-cli --cluster create --cluster-replicas 1 \
10.41.170.30:6381 10.41.170.40:6381 10.41.170.130:6381 \
10.41.170.30:6382 10.41.170.40:6382 10.41.170.130:6382

Use redis-cli --cluster info <any-node> to view cluster status and redis-cli -c -h <host> -p <port> for interactive commands.

Spring Boot Integration

Define properties:

spring:
  redis:
    master-slave:
      master: 10.41.170.130:6380
      slaves:
        - 10.41.170.100:6381
        - 10.41.170.119:6379
    timeout: 10s
    lettuce:
      pool:
        min-idle: 5
        max-idle: 10
        max-active: 20
        max-wait: 1000ms

Configure a RedisConfig class that creates a RedisTemplate with StringRedisSerializer for keys and a fast JSON serializer for values, and a LettuceConnectionFactory that reads from replicas.

Testing

Use Redis CLI or Postman to write keys (e.g., test_key:1003) to the master and verify automatic replication to slaves. Spring Boot endpoints can read/write the same keys, confirming that the cluster and Sentinel mechanisms work correctly.

Typical Use Cases for Redis

Session management for distributed applications.

In‑memory caching to accelerate data access.

Distributed locks using atomic commands.

Atomic counters for analytics and rate limiting.

Rate limiting and throttling of API calls.

Generation of globally unique identifiers.

Shopping cart storage with fast read/write.

User retention analysis via time‑stamped events.

Lightweight message queues with Pub/Sub.

Real‑time leaderboards using sorted sets.