Redis can be identified as a Remote Dictionary Server that is mainly designed for speed. In addition, it is widely utilized as an in-memory cache and NoSQL database. As a database or cache, it is vital to provide a high rate of data access, high availability, data sharding, and scalability features. Redis introduced Sentinel and Cluster solutions to address the mentioned aspects.

Redis Cluster

The Redis Cluster technology that was introduced from version 3.0 enables the horizontal scaling for a given Redis deployment. With Redis clusters, the data is split across multiple cluster nodes that provide a consistent and reliable data service layer for applications.

It is a must to have at least three master nodes for a cluster to function properly. In addition, each master node should have at least a single slave node. Furthermore, Redis clusters enable high availability up to some degree by promoting a slave node associated with a failed master instance in a hardware/software or network failure.

Each cluster node communicates with other nodes using a binary protocol-based node-to-node communication channel. In addition, each node is open to client connections by utilizing the standard TCP port.

The following is a high-level sketch of a basic Redis cluster configuration:

Pros:

• Data Sharding
  • The data is shared among multiple nodes and it can be dynamically adjusted.
  • Since there is no central control center, the data is split among nodes automatically.
• Scalability
  • A cluster can scale up to 1000 nodes. Nodes can be removed or added dynamically.

• Automatic Failover

• • Redis cluster supports master-slave architecture and it enables the built-in master failover technique.

 
Cons:

• Not Completely Highly Available
  • In case of a major failure, most of the master nodes might go down which causes the whole cluster to go down.
• The High Number of Nodes Per Single Cluster
  • It is a must to have at least three master instances and a single slave node per master which ends up with six nodes to set up a properly functioning Redis cluster.
• No Guarantee of Data Consistency
  • Redis cluster master replication is processed asynchronously and it might affect the consistency.
• Lack of Client Library Support for the Redis Cluster
  • There are a minimal number of client libraries that support the Redis cluster implementations.
• Single Layer Replication
  • The Redis cluster master replication architecture allows only a single layer. A given slave instance can replicate only the master node.
• Redis Cluster May Lose Acknowledged Writes in Some Scenarios

• Data Handling Is More Complicated

• • Due to the data sharding, cluster admins should manage multiple RDB and AOF files. Furthermore, extra effort is needed to aggregate persistence files from multiple nodes to make a backup.

Redis Sentinel

Redis Sentinel is a high-availability approach for Redis deployments that runs as a separate program in the background. It brings a lot of features to your Redis deployments by constantly checking the master and slave node status, notifying the significant changes related to the monitored instances via an API, initializing the automatic failover process when a master failure occurrs, and acting as a source of authority for clients to find out the currently active Redis master node IP address.

A Redis sentinel setup can be implemented using at least three sentinel nodes which can avoid most of the problems in a given Redis deployment. Furthermore, in a given sentinel configuration, the Quorum value defines the minimum number of sentinel nodes that should confirm when a master is failed.

Generally, the Redis Sentinel is primarily employed to support the high availability of a Redis database where it performs better than in the clustering approach.

The following is a high-level illustration of a minimal Redis sentinel configuration:

Pros:

• Minimal Number of Nodes
  • A completely working Redis sentinel deployment can be formed with three nodes.
• Highly Available
  • Redis sentinel deployment can survive critical node failures without any human intervention.
  • It can function when at least a single master instance is available even though every slave is down.
• Enhanced Master Replication
  • In Redis Sentinel deployment, several slaves can replicate a given master instance.
• Simplicity & Flexibility

• Redis sentinel is very easy to maintain and has flexible configuration options as well.

 
Cons:

• No Sharding Supported
  • Data sharding is not possible. Hence, large-scale data sets accessibility may cause the performance to degrade.
• Lack of Scalability
• Outdated Reads
  • Usually, the slave nodes serve reads in Redis sentinel deployment. Due to the asynchronous replication, reads may not be up to date.
• Redis Sentinel Should be Supported by the Client Library
• Slave Node Doesn’t Act as a Backup Node

Redis Sentinel Vs Cluster

Redis cluster and sentinel are two approaches where each addresses different aspects related to a Redis deployment. To highlight, the Redis cluster approach is more suited for complicated implementations that deal with massive datasets where it provides automatic data sharding for better read/write querying performance, automatic master failover, and replication with high availability up to some extent. Furthermore, the Redis cluster nodes can be scaled effortlessly.

On the other hand, the Redis sentinel is more focused on smaller implementations with high availability in mind.

Availability

Redis cluster doesn’t fully support high availability. Because, if the majority of the masters are not available, the cluster may go down. In contrast to the cluster approach, the Redis sentinel offers high availability without any human intervention. Most importantly, the sentinel can survive even with a single running master instance when a critical failure occurs.

Data Sharding

Redis cluster offers sharding capabilities where the data is distributed among multiple nodes when clients have network access to all the nodes. It enables increased performance and data storage capacity.

On the other hand, Redis sentinel does not offer sharding capabilities. Because the sharding causes the imbalance utilization of the master and slave.

Replication

Both Approaches offer master replication with some limitations. Redis sentinel allows replication for multiple layers where several slave nodes can replicate from a given master instance. In contrast, the Redis cluster approach doesn’t allow replication for multiple layers. It is only capable of replicating the master instance to a single slave node. Both approaches compromise the consistency due to the async replication.

Scalability

Redis clusters are highly scalable. It supports up to thousand nodes in a given single cluster setup. Furthermore, Clusters allow adding and removal of nodes dynamically and effortlessly. Redis sentinel is not scalable and writes are directed to the master instance, hence the sentinel is not able to deal with the read-write separation issues.

Architecture

A fully functional Redis sentinel can be built with just three nodes. But to set up a Redis cluster, it requires at least three master nodes and three slaves attached to them which is more costly than in Redis sentinel deployment.

Conclusion

To summarize, the Redis Cluster approach is more focused on complex deployments when high scalability, high performance, and high data storage are important and the high availability is not significant. On the other hand, Redis sentinel is primarily built for simple applications that are mainly focused on high availability. As compared, both solutions come with their pros and cons but to support the end users with more finely-tuned Redis deployment.