Redis Replication, Sentinel, and Cluster: Mechanisms, Configuration, and Best Practices

The author, a senior architect, introduces Redis as a single‑threaded in‑memory store whose read/write speed is sufficient for most caching scenarios, but large‑scale services may need higher performance through clustering.

Redis

Redis is single‑threaded; a simple benchmark shows 110,000 reads/s and 81,000 writes/s for 256‑byte values with 50 concurrent clients issuing 100,000 requests each. For very high traffic, a cluster is recommended.

Redis provides three clustering strategies:

Master‑Slave Replication

Cluster

Sentinel

1. Master‑Slave Replication

In master‑slave replication there are two roles: master (read/write) and slave (read‑only). The master automatically pushes data changes to its slaves.

1.1 Characteristics

The master handles read/write operations and synchronizes changes to slaves.

Slaves are read‑only and receive data from the master.

A master can have multiple slaves, but a slave is bound to a single master.

1.2 Working Mechanism

When a slave starts, it sends a SYNC command to the master. The master creates a snapshot, sends the RDB file to the slave, and then streams subsequent write commands.

After initialization, every write command on the master is forwarded to the slaves to keep data consistent.

If the connection breaks, the slave reconnects and a full synchronization is performed automatically.

1.3 Configuration

Only the slave needs configuration. Example: slaveof 192.168.0.107 6379 If the master requires a password: masterauth master-password Check replication status:

info replication

1.4 Advantages

A single master can synchronize with multiple slaves.

Slaves can also accept connections from other slaves, forming a graph‑like replication topology.

Both master and slaves serve requests in a non‑blocking way, allowing reads during synchronization.

Slaves can provide read‑only services, reducing read load on the master.

Masters can offload persistence tasks to slaves.

Read‑write separation improves scalability.

1.5 Disadvantages

No automatic failover; a master or slave crash requires manual IP switch or restart.

Data not yet synchronized may be lost during a failover, causing inconsistency.

Full synchronization requires a forked snapshot, demanding sufficient memory and causing performance spikes.

Online scaling is difficult; capacity must be over‑provisioned.

In large‑scale or high‑availability scenarios, master‑slave replication is generally not recommended.

2. Sentinel

Sentinel, introduced in Redis 2.6 and stabilized in 2.8, monitors master‑slave health, performs automatic failover, and updates configuration files accordingly.

2.1 Sentinel Functions

Monitors master and slave status.

When the master fails, promotes a slave to master.

Updates redis.conf and sentinel.conf on role change.

Sends alerts via API to administrators.

Multiple sentinels monitor each other.

Multiple sentinels can monitor the same Redis instance.

2.2 Working Mechanism

Sentinel reads sentinel monitor master-name ip port quorum to discover masters.

It opens two connections to each master: one for subscribing to sentinel:hello channel, another for periodic INFO commands.

Periodically sends INFO, sentinel:hello , and PING to masters, slaves, and other sentinels.

If a node does not respond within sentinel down-after-milliseconds , it is marked subjectively down (SDOWN).

When a quorum of sentinels agrees, the master is considered objectively down (ODOWN) and a leader sentinel is elected using a Raft‑like voting process.

The elected leader selects the best slave (based on priority, offset, and ID) to promote to master, then notifies other nodes and updates configurations.

2.3 Configuration

Sentinel uses sentinel.conf. Example entry: sentinel monitor mymaster 192.168.0.107 6379 1 Start sentinel: redis-server sentinel.conf --sentinel & Check status:

bin/redis-cli -h 192.168.0.110 -p 26379 info Sentinel

3. Redis Cluster

Redis 3.0 introduced native clustering. Each node stores metadata about all masters and slaves and communicates via a “cluster bus” on ports +10000.

3.1 Features

Every node talks to n‑1 others via the cluster bus.

Slots 0‑16383 are mapped to nodes; the cluster maintains slot‑to‑node mapping.

Clients connect to any reachable node; if the key belongs to another node, a redirection is returned.

Management is done with the Ruby script redis-trib.rb (or redis-cli --cluster in newer versions).

Failover requires a majority of nodes to agree that a master is down.

3.2 Configuration Steps

Install Ruby (>=2.2) and the Redis gem.

yum install ruby
yum install rubygems
gem install redis

Edit each node’s redis.conf:

bind 192.168.0.107
port 6380
dir /usr/local/redis-cluster/6380/
cluster-enabled yes
cluster-config-file nodes-6380.conf
cluster-node-timeout 15000

Start all nodes.

redis-service …/6380/redis.conf
redis-service …/6381/redis.conf
...

Create the cluster (confirm with yes):

redis-trib.rb create --replicas 1 192.168.0.107:6380 192.168.0.107:6381 192.168.0.107:6382 192.168.0.107:6383 192.168.0.107:6384 192.168.0.107:6385

Connect to any node: redis-cli -c -h 192.168.0.107 -p 6381 View cluster nodes: cluster nodes The output shows three masters and three slaves successfully created.

3.3 Adding Nodes

Use cluster meet ip port to add a new node to the cluster.

Other Cluster Implementations

Middleware

twemproxy (nutcracker) is a lightweight proxy that performs client‑side sharding, reducing the number of direct connections to Redis instances. It is stateless and can be made highly available with keepalived.

Codis provides a distributed Redis solution with a proxy layer, handling request routing and online data migration transparently.

Client‑Side Sharding

Jedis supports sharding via consistent hashing (MurmurHash) with virtual nodes, allowing key‑tag patterns for collocating related keys. While flexible, it requires the application to handle possible data loss during rebalancing.

Additional Resources

The article concludes with links to interview questions, open‑source projects, and further reading on Redis use cases, high‑availability design, and performance tuning.