Redis provides three clustering solutions: Master-Slave Replication, Sentinel Mode, and Cluster Mode, each with different use cases and characteristics.
1. Master-Slave Replication
Working Principle: Master-Slave Replication means one Redis node acts as the master, and other nodes act as slaves. The master handles write operations, while slaves handle read operations. The master synchronizes data changes to the slaves.
Features:
- Read-Write Separation: Master handles writes, slaves handle reads, improving system throughput
- Data Backup: Slaves are complete replicas of the master, providing data redundancy
- Failover: When the master fails, manual intervention is needed to promote a slave to master
Configuration:
bash# Add to slave node configuration file slaveof <master-ip> <master-port>
Disadvantages:
- Manual failover required when master fails, no automatic failover
- Master's write capacity is limited, no horizontal scaling
2. Sentinel Mode
Working Principle: Sentinel Mode adds sentinel nodes on top of master-slave replication. Sentinel nodes monitor the health of master and slave nodes. When the master fails, it automatically promotes a slave to master, achieving automatic failover.
Features:
- Automatic Failover: When master fails, automatically elects a new master
- Monitoring: Real-time monitoring of master and slave health
- Notification: Notifies administrators when master fails
- Configuration Provider: Clients can get current master address from sentinel
Sentinel Workflow:
- Sentinels periodically send PING commands to master and slaves to check health
- If master doesn't respond within specified time, sentinel marks master as subjectively down
- When enough sentinels consider master down, master is marked as objectively down
- Sentinels elect a leader sentinel to handle failover
- Leader sentinel elects new master from slaves
- Other slaves reconfigure to point to new master
Configuration:
bash# Sentinel configuration file sentinel.conf port 26379 sentinel monitor mymaster 127.0.0.1 6379 2 sentinel down-after-milliseconds mymaster 30000 sentinel parallel-syncs mymaster 1 sentinel failover-timeout mymaster 180000
Disadvantages:
- Master's write capacity still limited, no horizontal scaling
- Sentinel nodes themselves can become single point of failure
3. Cluster Mode
Working Principle: Redis Cluster uses a decentralized architecture, sharding data across multiple nodes. Each node is responsible for a portion of data, achieving data sharding through hash slots.
Features:
- Data Sharding: Distributes data across multiple nodes, enabling horizontal scaling
- High Availability: Each master can have multiple slaves, automatic failover when master fails
- No Central Node: All nodes are equal, no single point of failure
- Automatic Failover: When master fails, slave automatically promotes to master
Hash Slot Mechanism:
- Redis Cluster has 16384 hash slots (0-16383)
- Each node is responsible for a portion of hash slots
- Use CRC16(key) % 16384 to calculate the hash slot for a key
- Client locates the corresponding node based on hash slot
Configuration:
bash# Cluster configuration file redis.conf cluster-enabled yes cluster-config-file nodes.conf cluster-node-timeout 5000 cluster-require-full-coverage yes
Creating Cluster:
bashredis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 \ 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 \ --cluster-replicas 1
Disadvantages:
- No support for multi-key operations (unless keys are in same hash slot)
- Client needs to support cluster protocol
- Limited transaction support
Comparison of Three Solutions
| Feature | Master-Slave | Sentinel | Cluster |
|---|---|---|---|
| Data Sharding | No | No | Yes |
| Automatic Failover | No | Yes | Yes |
| Read-Write Separation | Yes | Yes | Yes |
| Horizontal Scaling | No | No | Yes |
| Complexity | Low | Medium | High |
| Use Case | Simple read-write separation | High availability | Large-scale data |
Selection Recommendations
- Small data volume, need read-write separation: Use Master-Slave Replication
- Small data volume, need high availability: Use Sentinel Mode
- Large data volume, need horizontal scaling: Use Cluster Mode
- Production environment recommendation: Use Sentinel Mode or Cluster Mode, choose based on data volume
In actual applications, most production environments choose Sentinel Mode or Cluster Mode to ensure system high availability and scalability.